Silver Stripe Blog

In my talk at Agile Bengaluru, I asked “What is velocity? What does velocity measure? Is it useful?”

What is velocity?

Everyone was united on this – velocity is the aggregate of story points (or any estimate unit you use) completed in the sprint.

What does velocity measure?

I got a bunch of answers for this

• Velocity measures the amount of work (capacity) you can do in a sprint
• Velocity measures the amount of value delivered in the sprint
• Velocity measures the productivity of the team

The number of different answers illustrates perfectly that we don’t have a common understanding of velocity. Everyone knows how to calculate it, everyone knows how to use it, but we don’t understand the more fundamental question of what it is supposed to measure.

Let us take a stab at answering this question.

Is velocity a measure of value? This idea comes from the fact that we don’t get credit for partially complete work, thus creating the notion that velocity is measuring value. But clearly it is not. You can have large stories that deliver small value and small stories that deliver large value. Since velocity just aggregates the story points, it can’t be a measure of value.

Is velocity a measure of productivity? This idea comes from the fact that as the productivity goes up, you get more work done causing the velocity to increase. The other side is that the velocity often changes when there is no underlying change in productivity.

Is velocity a measure of capacity? This idea comes from the way velocity is used to plan the stories that can be scheduled in a sprint. But if velocity is a measure of capacity, then we should not cut the velocity for partial work and get a boost next sprint when a tiny bit of work is done to complete it. After all, if the capacity remains the same, then why should the metric change?

Now take a look at the ways velocity is used and the interpretation

• To plan the sprint: Velocity measures capacity
• To forecast releases: Velocity measures capacity
• No partial credit: Velocity measures value
• Trying to increase velocity: Velocity measures productivity
• Not counting bugs/refactoring in the velocity calculation: Velocity measures value
• Counting bugs/refactoring in velocity calculation: Velocity measures capacity

Notice an interesting contradiction there. Should you count bugs/refactoring work towards velocity? Some teams say no, because these don’t add value. Thats a value view of velocity. In this view, if I do a sprint of refactorings, my velocity will be zero. I can’t use that number for the next sprint planning, because sprint planning uses a capacity view of velocity.

Is velocity a useful metric?

I suppose velocity could be a useful metric, provided it is used consistently. The problem is that in different contexts it gets different meanings, often contradictory to how it is used in another context. Velocity also starts to break down when you start looking at special cause variations. For example, holiday seasons will have one-time low velocity, which should not really be incorporated into the next sprint.

Another problem is uneven work, for example in a maintenance project, you may have work for a day in one sprint, and for two days in another sprint. A flow based system is superior here.

Yet another problem is divided work, where someone works on two projects at the same time. The velocity could oscillate based on how time is divided among the projects.

So,

• if the team is stable
• and there is one project worked on at a time
• and special causes are not considered
• and there is enough work to use consistently the same capacity
• and velocity is applied with a consistent interpretation
• then velocity is useful

What is the alternative to velocity? I think Lead and cycle time are better metrics to look at. More on them in another post.