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