Velocity Is a Useful Metric But Not a Crystal Ball

crystalballI’ve criticized metrics in this blog before and I’m doing it again. I’m really a fan of metrics when they’re applied properly and interpreted correctly. Unfortunately, metrics are often misapplied and misinterpreted resulting in poor decision-making.

That said, let’s take a closer look at a popular Scrum metric — velocity. Here is the definition found at the Scrum Alliance:

“In Scrum, velocity is how much product backlog effort a team can handle in one sprint. This can be estimated by viewing previous sprints, assuming the team composition and sprint duration are kept constant. It can also be established on a sprint-by-sprint basis, using commitment-based planning.

Once established, velocity can be used to plan projects and forecast release and product completion dates.

How can velocity computations be meaningful when backlog item estimates are intentionally rough? The law of large numbers tends to average out the roughness of the estimates.”

Makes sense, right? Pay particular attention to the phrases “…assuming the team composition and sprint duration are kept constant” and “The law of large numbers tends to average out the roughness of the estimates.”

Scrum teams usually measure their software development effort in story points so velocity is the number of story points the team can finish during a sprint. You could use hours or any other measure you like. The key point is to develop a reliable way of sizing units of work (stories).

In a perfect world, every sprint would deliver the same number of story points. A velocity chart would then create a flat line as shown here:

velocityflat

This chart shows a steady velocity of 20 story points delivered per sprint. If a development team could achieve this, it would indicate that they are very good at sizing stories and very good at getting the stories to ‘done’ during each sprint. (It might also indicate that they are very good at gaming the system but let’s not go there.)

In the real world, velocity charts tend to look more like this:

velocityvariable

The number of story points delivered varies — at times, it varies widely. There may even be sprints where the velocity drops to zero because the team encountered a major unforeseen impediment.

Does this mean velocity is a useless metric?

Yes, if your expectation is that velocity can predict the future. It can’t. Velocity can only tell you what has already happened. It offers a suggestion of what can be expected in the future — over several sprints — but it can’t tell us how many story points will be delivered in the next sprint.

In other words, if the team is averaging 20 story points per sprint over several sprints, they are most likely to deliver 100 story points over the next 5 sprints. Will they deliver 20 story points during the next sprint? Your guess is as good as mine.

Warning: I just made a huge assumption in stating that 100 points can be expected in the next 5 sprints. I assumed that the team would remain intact AND that the software environment would remain fairly static. If there’s a major change in personnel, technology or tools, velocity is likely to decline sharply before rebounding.

Bottom line: I like the velocity metric and I recommend you track it. Just don’t expect it to be a crystal ball.

photo credit: Daniele Muscetta via photopin cc

Updated: May 2, 2013 — 9:51 pm