Chapter: ITERATION VELOCITY AND CAPACITY
When iteratively planning an Agile project where the team partitions work into timeboxed iterations, understanding capacity is very important. Planning an iteration is very much like using a bucket to scoop water out of a pool, where the pool represents the complete set of backlog items on your project and the bucket represents the amount of work that can be accomplished in a single iteration. Understanding how much water a bucket holds will give you an idea of how many buckets are required to empty the pool. Similarly, understanding how much work your team can deliver in an iteration will give you a good idea of how long the project will take.
An iteration’s capacity is the amount and size of the backlog that can be completed in a single iteration. Refer to the following table:
In Table 1 we can see that 6 backlog items were added to an iteration, two of which were not completed within the iteration. In this case, the team would consider their velocity to be 17 after adding up all of the estimated sizes for all of the backlog items that were complete in the iteration. This number will then act as a guideline for scheduling work for the next iteration as the team has recognized that they scheduled too much work in a single iteration.
Of course, not every iteration will have the same velocity, however, over time the average iteration velocity should begin to become an increasingly accurate predictor of how much work the team can produce in a single iteration. Many teams like to keep a high and low capacity for their iterations, as demonstrated in Figure 6. This allows teams to accurately predict how much work they can accomplish in future iterations and set appropriate expectations with stakeholders.
How the TeamPulse team does it - Planning
The Telerik TeamPulse team uses 2 week sprints and aims to be “done done” by the end of every sprint. This means that every 2 weeks, the team literally has a completely shippable product – including tested functionality, documentation and installer packet.
Each sprint starts with a planning session, lasting from 90 minutes to 2 hours. Prior to the sprint planning session, there is a grooming session where a couple team members from each role sit together with the product owner and review the user stories for the next iteration. This way, we make sure the user stories we review during planning are as mature as possible.
During the planning session, each team gets aligned with the goals for the iteration, reviews the stories, conducts group estimation (using planning poker to get relative estimates), decomposes the stories into work (TeamPulse tasks) and produces the initial sprint plan. The team also works to provide the initial set of acceptance criteria for each story—something used to define what “done” means for the story.
At the end of each iteration planning session, we always run the TeamPulse Best Practices Analyzer (BPA) to see if the completed work conforms to development best practices. The BPA runs through the items planned for the iteration and checks for stories without estimates, tasks or acceptance criteria, as well as many other factors critical for the success of each iteration and project. It even points to those stories, so we can quickly go in and update them.