Velocity planning or capacity planning (or both)?
Posted on | June 12, 2009 | 2 Comments
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.
Comments
2 Responses to “Velocity planning or capacity planning (or both)?”
Leave a Reply
Recent posts- How to create a Gantt Chart in Excel 2007 or 2010
- Better IT results with Lean Six Sigma DMAIC, a data migration example
- Tips for lowering the agile adoption threshold
- Slides seminar “Lean & Agile IT” published (Dutch)
- Organizing seminar “Lean & Agile IT: beter resultaat, betrokkenheid en IT volwassenheid” (Dutch)
- Whitebook ‘Better IT results with Lean Six Sigma DMAIC’ (Dutch)
- Managing the control/progress balance
- Gantt Chart template for Excel 2007 or 2010
- What’s the connection between the Montessori Method, The Toyota Way and Agile IT?
- New cool videos on Leadership and Practical Wisdom
My Company
Booklist
Planned books:
- Making Sense of Change Management: A Complete Guide to the Models, Tools and Techniques of Organizat by Esther Cameron, Mike Green
- Freedom from Command by John Seddon
- Do the Right Thing: How Dedicated Employees Create Loyal Customers and Large Profits by James F. Parker
- Presentation Zen: Simple Ideas on Presentation Design and Delivery (Voices That Matter) by Garr Reynolds
- Getting Things Done: The Art of Stress-Free Productivity by David Allen
Current books:
-
Managing portfolios of change with MSP for programmes and PRINCE2 for projects: Integrating MSP and by Chris Venning
Recent books:
- Het Groot Werkvormenboek / druk 1: dé inspiratiebron voor resultaatgerichte prestaties, vergaderinge by S. Dirkse-Hulscher, A. Talen
- Managing successful programmes: Office of Government Commerce by Rod Sowden … [et al.]
- Performance Leadership: The Next Practices to Motivate Your People, Align Stakeholders, and Lead You by Frank Buytendijk
- Hard Facts, Dangerous Half-Truths, and Total Nonsense: Profiting from Evidence-based Management by Jeffrey Pfeffer, Robert I. Sutton
- Knowing-Doing Gap, The: How Smart Companies Turn Knowledge into Action by Jeffrey Pfeffer, Robert I Sutton
November 2nd, 2009 @ 12:21
[...] composition, no holidays, no illness, no sudden fires to put out, etc..etc.. I while ago I read this post from my colleague Martin van Borselaer. In that post he proposes [...]
September 7th, 2010 @ 07:59
You are right about capacity: in fact every team member should come to planning with data about his capacity for the next sprint – planned vacation, training, etc.
However, requiring developers to record actual hours spent seems like overkill. Why not calculate sprint capacity in story points? If you know a point = half a day, and Joe will be absent one day, remove 2 story points from team’s regular sprint capacity and you are done.
There is a reason we usually don’t mix real hours and story points in this way: simplicity. Many have found that the simpler way works “well enough” that the team can stop reporting actuals. What is more important than actuals is estimates and learning to estimate better, and they get this from standups and burndown. You might try it to see if it works well enough, and retrospect it after three sprints!
Have fun!
deb