The first article set the terms and language that I used when using Velocity as a metric with Agile teams. In short, the main point of the article is that there are three types of Velocity involved:
- Daily Velocity
- Sprint Velocity
- Average Velocity
This article will detail the information contained in each metric and how to use it to improve team productivity.
Uses of daily velocity
Most blogs, tutorials and books describe how to look at burndown charts. In terms of velocity:
- In (1) your team is going slower than the planned velocity.
- In (2) your team is going at about the planned velocity.
- In (3) your team is going faster than the planned velocity.
For these scenarios, most agile practitioners tend to stick to looking only at the burdown chart. And during the daily answer the usual three questions. However, the are risks involved in giving too much weight to Velocity and the burndown chart. As mentioned in the first post of this series, matching the estimated velocity is not the goal of a sprint. When looking at graphs on the shape like (1), (2) and (3) is also worth considering what other things we have learned in this print before choosing a course of action.
For example:
- If you are going slower (1), maybe it is worth taking a memento to explore WHY. Maybe this set of completed User Stories was a bit more complex than usual? Where you focusing on Quality (or other Non-functional attributes)?
- Likewise, if you are going faster (3), Have we missed anything? Is quality also on par with expectations?, or
- Is it just the result of natural variation?
But what is going on in (4)?
 (1) Ahead of plan |  (2) As planned |  (3) Later than plan |  (4) Problematic |
The good thing about velocity as a metric is that it is very sensitive to issues that go wrong in a sprint. And this sensitivity comes, in spite of the roughness of Story Point as a unit.
As a result, daily velocity is useful as a Heads-up display metric. A graph like (4) evidences that something is not flowing as it should be. In particular, a graph like (4) is a symptom of one of these causes:
- The user stories are not independent
- The user stories are not of similar size
- The estimation process is not shared by all peers
The sensitivity of the daily velocity will also allow you to identify issues stemming from team availability, and identifying variations in the stories, among others.
Uses of Sprint Velocity
Sprint velocity is a rear-view metric, a registry of the sprint productivity at the end of a sprint. As such, you are only able to measure it once the sprint is finished. So it is of little use for ongoing management of the Spirit.
However, tracking Sprint velocity feeds forward into sprint planning through Average Sprint Velocity.
There is not much you can use this metric for. Yet I’ve seen more wrong uses than right. As a measure of team productivity of a Sprint, you should expect variation. Teams optimising for predictability, fail to see their variation and quickly lose the information that this metric can provide. Another source of mistakes comes from organisations trying to use sprint velocity to compare the productivity of different teams.
Uses of Average Sprint Velocity
Average Sprint Velocity is a calculated metric that is useful for planning. As an average-based metric, it normalises the variation observable in consecutive measures of Sprint Velocity. Agile teams typically use the current measure of this metric to set an expectation of the amount of work that can be planned for a sprint.
Because of its direct use in Planning, this metric has more potential for misuse than Sprint Velocity. Some of these misuses came from forgetting that the metric is based on central tendency statistics. As such, it is sensitive to several fallacies. For example:
- Average-based metric tends to decay. If you always aim at the average, then it only takes one measure below average to decrease the average.
- Past as predictor: The previous (3,5,7…) sprint velocity measures used to calculate the average, are only relevant if there is a reasonable explanation that all other factors remain the same.
- Sprints of different lengths. If your sprints are not of the same length, then effort within the sprint and days changes, so you can not calculate Average velocity with the simple formula presented last week.
- Sprint of different efforts. Likewise, if your team composition changes, then you can not calculate Average velocity with the simple formula presented last week.
Parting thoughts
I do like to use velocity metrics to support an agile software development process. In particular, these metrics are quite sensitive and there is rich information to obtain from the variation brought about by this sensitivity.
However, I have often seen these misused and abused. To the point that quality and performance suffer.
Next week, I’ll close this series with frequently asked questions about velocity. If there is anything in particular you’d like to see there, post it in the comments.
