Calculating Capacity of an Agile Team

Photo by ohskylab
Velocity is an agile metric used for making long term schedule predictions. It gives you a range of possible release dates (given a set of user stories) or a range of stories to be delivered (given a fixed release date). Several people have written extensively on agile estimating and planning and the importance of hours and story points in the process.
Please note the emphasis on “long term”. What to do with the short term? How many story points are we committing to in the next iteration? The simplest approach is to commit to the number of story points delivered in the previous iteration. Or use the average velocity of the last 3 iterations. Or take all velocities of the last 5 iterations, eliminate the highest and lowest values and average the remaining three. Or… (I think you can figure out something useful yourself by now).
But. This is a ceteris paribus assumption. It assumes the same team 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 to:
- add up all hours really used for delivering stories in the previous iteration
- estimating how many hours we have available for delivering stories in the next iteration (correcting for holidays, illness and the like)
- use the ratio between (1) and (2) to derive the number of story points to commit to
At the moment Martin and I work on the same project and we have metrics from 8 iterations. It turns out that we have a sustainable pace of about 35 story points. It doesn’t really matter if someone is on a holiday, gets ill or we have to put out a fire. The number of available hours can vary up to 40 hours without having a significant impact on the velocity. Of course, this doesn’t hold up for extreme situations, such as extremely long holidays, illness, or that one specific user story you need those specialist skills for (BTW, if this happens regularly, you have a different problem – food for another blog post).
What does that tell us? We now know he team can safely commit to approximately 35 story points without “calculating” the available capacity, as long as we recognize that there will be no significant irregularities in the next iteration.
What should we do with the overhead to register hours worked? It doesn’t add much value to make a useful commitment. However, since the project also has stakeholders that are not so aware, interested or educated in lean and agile, it does add value in our communication to these people. Since it is a lightweight process, the effort to do it can be justified.
Alright, that makes sense! Thank you.