The Importance of Measuring Iteration Velocity and Capacity for Agile Planning

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 this table 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.

Decomposition into Tasks

Your backlog is normally comprised of requirements in the form of User Stories which depict the resulting value required by the users of the system. During iteration planning, teams take the highest value requirements and assign them to the current or next iteration, filling the iteration to capacity. Agile teams typically do not decompose requirements into work tasks until they are assigned to an iteration. Agile teams spend the first few hours of each iteration going through iteration planning, and a part of that process is the decomposition of requirements into work that can be completed by team members. This is more commonly referred to as just-in-time work decomposition. Task decomposition is not typically done until the requirements are assigned to an iteration. This ensures that the entire team can collectively review and discuss each requirement and determine a common approach to proceed.

Task decomposition prior to iteration planning may result in considerable rework and waste. Just as there is much benefit in the entire team reviewing and understanding each backlog item/requirement, there is similar value in the whole team working to collectively decompose the work required to deliver each requirement. For example, junior members of the team get exposed to the knowledge and techniques of more experienced team members. Teams can also reduce errors and increase quality by

contributing to the implementation approach together. They can further help each team member have a strong understanding of all parts of the system regardless of which part they worked on.

If you want to know more about Agile planning, download our free e-book- The Ultimate Agile Planning Handbook. It addresses the following topics:

• Timeboxing
• Optimizing iterations
• Prioritizing and sizing the backlog
• Using uncertainty and maturity to improve prioritization
• Improving predictions using velocity and capacity and more
• Most common challenges related to plannig and how to overcome them

Do you need a tool to manage your agile projects?
If you haven’t tried TeamPulse yet, try it now!