You have a development team. Your stakeholders and project sponsors want to make the most out of your team. They’d like to see your current capacity and squeeze out as much as they can out of every resource you’ve got.
Do they have free time? Put them on another project.
Can they help out here? Put them on that project.
Ugh. Kill me. There has got to be a better way. Capacity is an interesting metric to measure. Some people simply do an equation like so:
Working Hours Available per Day (WH) ((x)times) Days Available This Iteration (DA) ((=) equals) Capacity
WH x DA = Capacity
But this seems way too over simplistic! I mean, are our developers really working 8 hours a day on code? What every happend to “ideal man day?” In teams I’ve worked with, an ideal man day is 5-6 hours in length. In many cases, 5 hours a day seems more reasonable. We have to account for interruptions (hopefully not many), meetings, and other things that come up in the day. A good general rule is that we shouldn’t try to exceed 70% of an individuals capacity. In reality it’s closer to 50%.
The problem with the 100% utilization mindset is that we have assumed that our outcomes of an iteration are fully deterministic… but we all know pragmatically that this isn’t true. Software development is unpredictable at times!
A couple of steps to help us look at capacity when it comes to our projects:
- Individuals calculate realistic capacity
- Applied honest estimates to their tasks
- Targeted a maximum capacity of 50%-70%
- Understand capacity over the long haul with velocity and story points – What is the average story point completion by team/individual?
When capacity planning is done well we can feel good that we all have done our best to provide a realistic commitment to achieving the completion of all stories for the iteration.
[Image Source: technet.microsoft.com]