Traditionally (if that even exists with agile project management) the team’s velocity is expressed in the number of story points delivered per iteration (sprint).
In an ideal (theoretical) world, the next iteration’s velocity should be the same (or slightly better) then the last one. In the real world this is not the case. One cause is the fact that people don’t work all the time. They go on holidays, become ill, need training, etc. and don’t distribute there time off evenly over all iterations. Less capacity means less products delivered means less story points delivered.
The difference between the projected amount of story points and realized amount becomes even larger when the sprint duration is short (for instance a week) and the team is small in size.
In the long run it probably doesn’t matter that there’s a difference between estimated and realized story points for a specific sprint, but that’s not good enough for me:
- I want the team to have an amount of workload that is realistic, is taken seriously and is something the team can commit to.
- I don’t want to explain to the customer the differences between projections and realization when I can avoid it.
- I need a more realistic planning for the near future when a specific release approaches. Estimating based on the long run doesn’t do the job.
That’s why I do both velocity planning and capacity planning.
This is how it works:
- Each team member registers on a daily basis in Excel the amount of hours they have worked per user story.
- And the end of the sprint I calculate the total amount of worked hours.
- Dividing the amount of delivered story points by the amount of worked hours gives me the sprint’s velocity: man-hours per story point.
- Before the next sprint planning session I determine the availability of the individual team members during that sprint and summarize that into the available man-hours. Then I divide the available man-hours by the velocity (expressed in man-hours per story point) and I have the amount of story points to be delivered by the next sprint.
Measuring and reporting of velocity in man-hours per story point in stead of story points per sprint is much more precise and more transparent. It makes it easier for me explaining the differences in delivered story points per sprint. It also helps me creating better forecasts and a more precise release planning. Furthermore, the team likes to have forecasts that makes sense and don’t mind the little amount of paperwork involved.
