If they're anything like my team, velocity can often be less of a science and more of an art, or rather, a finger in the air/gut feeling that there's too much or too little work in the sprint.
We wanted to change this, and learn more about our velocity, so the first step was to at least get an idea of some basic metrics. I find it hard to remember, but there was actually a time before we estimated stories and gave them story points.
When the team was first formed, we tried estimating in hours, and eventually shifted to story points using planning poker (because they are more abstract, allow for mutual calibration and take into account effort, complexity and time).
We tried pointing for quite a while before we started to arrive at a more consistent velocity. It took about 14 sprints before we had an understanding of what we were capable of as a team.
Our velocity (the tall column on the left is a fix version where we threw legacy stories to clear them out).
But we still had the issue of not knowing exactly how much we could commit to in the next sprint, because whenever we used the previous sprint as a guide to capacity for the next sprint, there were always mitigating factors and "exceptions" why the velocity was higher or lower.
Finally, we came up with 2 practices which seemed to make a big difference.
- Rather than looking at the last sprint the gauge estimated velocity for the upcoming sprint, take the average of the last 3 sprints and this will give you a better idea of how your team performs over time.
- Estimate take taken for absences such as Public Holidays, Vacations and Training. Story point these absences as you would for a piece of development work, and you will begin to take people's time away from the office into account when determining capacity for the sprint
What techniques do you use in order to understand your team's capacity for a sprint? Do you estimate in hours? Or story points? Or both?