As I mentioned before our approach to Agile adoption has been to go by the book and deviate based on the context at hand later on. One of the practices that we use at Sprint Planning is to calculate capacity at 6 hours a day and load individuals up to 75%-80% of their capacity. This technique has been introduced by an external coach earlier, and as we begin revising the processes we have, people look for reasoning behind this technique. Surprisingly enough I found that nay people were confused, so I came up with an explanation that at least makes sense to me.
1. We estimate tasks in Ideal Hours. Ideal Hours are the time required to complete the task if there are no distractions. So, for example a task estimated at 5 hours might take 2 calendar days for someone who is dragged into several meetings, or has context switch to help another developer or pulled into support issue.2. When we do sprint planning we compare capacity vs. amount of work that needs to be done in this sprint. In order to compare apples to apples, we have to calculate capacity in Ideal Hours as well. The standard practice is to use 6 productive hours a day for such exercise (I have seen it in references to Agile projects as well as traditional projects).
3. When a developer calculates his capacity for a sprint she multiplies “days in sprint” times 6 hours and come up with number of hours that can be dedicated to that team in that sprint. If she were to use 8 hours for that exercise she would be allocating a nonproductive hours for actual task work which may not be realistic.
4. Now, we know that comparing capacity against the amount of work to be completed is just part of the story. This comparison does not take into account dependencies between tasks, the fact that QA are loaded heavily in the end of the sprint, while developers are loaded more in the beginning and the middle of the sprint, the fact that user stories are “negotiable” in that they leave space for making decisions later on during the sprint and therefore new tasks arise during the sprint, the fact that developers are optimistic at estimates etc. If we were to plan for 100% everything would be on a critical path and the slightest mistake would cause user story to carry over. 80% rule creates the artificial buffer that covers for the former items.
Is 80% the right figure for every team? Perhaps not... perhaps each team should determine the percentage that makes sense for them.
