RallyDev.com
The Agile Blog is proud to present the first post from our newest contributor, Agile Coach Ben Carey
As part of our coaching at Rally, we usually recommend that new Agile teams use capacity as a countermeasure for not having a historical velocity. Considering individual and team capacity can help the team make an informed commitment for their iteration plan if they don’t have a historical velocity.
One general way to calculate the capacity can be seen below:
A team can use their individual capacities to indicate the maximum theoretical amount of work that each individual can complete in an iteration. Reviewing individual capacities against task estimates can help the individuals not over-commit and also help the team determine the amount of risk in committing to the stories that have been chosen for an iteration.
You can see your utilization percentage in Rally by looking at the Team Status page. As a general rule, I usually recommend that a team try not to exceed 70% of their capacity for each individual on the team.
There are many times that this recommendation is met with resistance because of the basic assumption that 100% utilization (total work divided by capacity) is the ideal state. I’m often asked to justify my general rule of 70% and asked why I would pick a number that is lower than the maximum.
Why I recommend capping individual capacity at 70%:
At a basic level, it seems to makes sense that we want everyone to run at full capacity. If the capacity exists, why shouldn’t we use it? Why would we ever want someone to do six tasks if they have the capability to do eight?
The problem with the 100% utilization mindset is that we have assumed that our outcomes of the iteration are fully deterministic.
When we consider the delivery of software, we need to acknowledge that a given set of inputs do not always result in a given set of outputs due to various degrees of variation in multiple aspects of the process (e.g. fire-fighting, estimation precision, defect introduction, management directives, interpersonal interaction, et cetera). In reality, software development activities are stochastic in nature.
If we look at other areas that are defined as being stochastic, we can build a mental model that can help us understand why 100% utilization isn’t the ultimate desirable state.
Let’s use a highway as an example…
A few general observations, you’ve likely noticed:
- The highway typically slows significantly below 100% utilization (the maximum number of cars that can fit on the road).
- The rate at which the highway slows is non-linear. Traffic will start to slow significantly faster between 80% and 90% utilization that it would between 40% and 50% utilization.
- When accidents occur or a lane shuts down, the effect is much more significant at times of high utilization (rush hour) than at times of low utilization (late night).
- The likelihood of reaching gridlock in a fully utilized highway becomes almost certain if it fills to capacity.
These observations can all be attributed to variation in the process.
In many ways, creating software is very similar to driving along a highway. There are a variety of unknowns, a variety of random events that might occur, continuous minor corrections, and a variety of options in getting to our end goal.
Luckily, software development isn’t the only place that we can look for to get some guidance on how to effectively determine our utilization.The nature of stochastic systems has been studied in many fields (telecommunications, fast-food restaurants, transportation systems, manufacturing, processors, and many others). In many of these fields, the general approach at modeling the variation in the system can be found in the study of queueing theory.
If we look to queueing theory, we can find some level of guidance with the following general capacity model.
This model shows us that utilization in a stochastic system follows a power-law distribution.
As we reach the upper levels of utilization, the nature of the work we are performing will likely lead to intense thrashing and will likely have impact across all areas of the work that we are performing. If anything doesn’t go exactly to plan or any other non-planned items come into play, we are likely to jeopardize our commitment.
Given the rate that these items tend to occur, I recommend not aiming for 100% utilization.
Bottom Line: When I see a team of individuals that have (1) calculated a realistic capacity, (2) applied honest estimates to their tasks, and (3) targeted a maximum capacity of 70% – then I feel good that they have done their best to provide a realistic commitment to achieving the completion of their stories for the iteration.
[ Check out more posts from Ben Carey by visitng his blog - The Sherpa Project ]
