Iteration Velocity |
This metric tracks the rate at which a team completes work across iterations, helping the team improve project predictability.
Main Description
### Overview The Iteration Velocity metric is used to measure the capability of the team. It helps identify the trend of how much work a team can complete in an iteration by tracking how much work it has successfully delivered in past iterations. Velocity is typically measured in story points or ideal days per iteration. If a team delivered 30 story points in their last iteration, their velocity is 30. Velocity can be used to predict whether the available resources will be able to complete planned tasks within the given iteration or release. Using a team's average velocity and available resources, a trend line can be plotted to determine when the remaining work will be completed. This should be factored in any time scope is added in the middle of an iteration. Velocity typically fluctuates within the first of couple iterations. If the velocity fluctuates drastically for more than one or two iterations, the team may need to focus on re-estimation or adjusting the release plan. Generally, velocity stabilizes between three and six iterations. ### Measurement Method Velocity = Number of units of work that the team has completed during a given iteration Units can be in points*, ideal days, days, hours or any unit that the team uses for estimation. * Points are units of relative size used in estimating tasks. These can be use case points, feature points, user story points, stakeholder request points, or Hi-Med-Low complexity. The higher the “points” the more functionality each work item is worth. Iteration Burndown is captured in IBM® Rational® Team Concert®. ### Measurement Analysis A good way to monitor Iteration Velocity over time is to use a trend line. The number of points is plotted on the Y axis, and the iterations are on the X axis. Ideally, the iteration velocity should accelerate over time as the team begins to work better together. If velocity goes up or down very quickly there could be a cause for concern to investigate. Downward Slope A trend line that goes down in later iterations is likely due to impending transition, and could be no cause for concern. However, if the line drops very quickly it could indicate a problem that is impacting the team's productivity. One possible cause could be quality issues. If the team is spending an increasing amount of time fixing defects, velocity will drop. The team needs to address the root causes of the poor quality. For example, the team might need to increase unit tests, bring in an experienced resource to help them with any new technologies, or introduce pair programming. There are other factors that can contribute to a drop in velocity. Have resources left the team? If so, the velocity of the team will drop and re-scoping might be needed. Has there been a change in communication channels or process that is impacting the team's ability to complete their work? In these cases, the team might just need a period of time to adjust to the changes. Or, whatever has changed might need to be reassessed to avoid the need to rescope the project. Flat A flat trend line indicates that a team is not increasing their productivity as the project progresses. Ideally, teams introduce incremental improvements that result in an upward sloping velocity trend line. But in some cases, factors such as increasing application complexity or large refactoring efforts cancel out those incremental improvements, resulting in velocity that does not change. Up and Down A trend line that oscillates up and down, but with no major up or down trends could indicate that uncompleted work is often carried forward to the next iteration. Because points are not credited for an iteration unless they are successfully delivered and accepted, some iterations have work credited as completed that was begun in an earlier iteration. At times this is due to stakeholder reviews taking too long to complete. Or, the team might be underestimating work. The graph below shows a velocity trend in units of points. In initial iterations, the team's velocity is little low, but it increases and stabilizes as the team proceeds toward the middle iterations. ### Metric Pitfalls and Advice [COH04] When calculating velocity, count only closed work items. Do not count work items that the team partially completed during the iteration. A good way to monitor is to graph team velocity during the whole iteration and for every iteration. Don't try to predict trends in velocity after only one or two iterations. The number of actual hours spent completing a task or a story have no bearing on velocity. Post big, visible charts in common areas where everyone can see them. A cumulative chart is useful, because it shows the total number of work items completed through the end of each iteration.
© Copyright IBM Corp. 1987, 2009. All Rights Reserved.