Velocity: The Misused Metric

Please tell me if this sounds familiar. You have started on a team new to you, and the manager or someone else asks you what your plan for estimation is. This leads to further discussion on what you will do with velocity. They want to increase the velocity. This conversation has happened to me more times than I care to count.

Before I get too far into this, I want to mention that velocity and estimation are nowhere in the Scrum Guide. Check for yourself; they are not there. Now that that is out of the way let us continue.

What is Velocity?

Asking for attention to velocity can stem from wanting Agile or Scrum to make the team faster. This focus on output only hinders the team and keeps them from improving as it focuses on output and not an outcome. Let us take a step back and take a quick look at velocity and how the number is reached.

When measured in story points, velocity is the average number of story points completed by a team in a sprint. This average is usually over the past 3+ sprints. Some teams measure their story points in a traditional 1,2,3,4… style, while others like to employ the Fibonacci sequence of 1,2,3,5,8…

More often than not, the desire behind measuring velocity is to see how fast the team is. Another want is to have some level of predictability. In some scenarios, the urge behind measuring velocity is to compare it to that of other teams. This is a big red flag if you see this.

Problems with Velocity

Measuring in these ways can lead to many issues. A Scrum team with a low velocity may be seen as underperforming. When in reality, they work on improvements but are constantly interrupted. This might cause a team to game the system and inflate their estimations to appear busier. Other teams may be inconsistent in their estimation of stories and maybe worried if they get a poor velocity. Yet another issue can be that teams focus so much on improving their velocity that they lose sight of delivering usable code.

Predictability measurements can be less predictable than initially thought. If you got 40 points worth of work completed this past sprint, you should get around 40 points next sprint. Sometimes it is taken to the level of if you get 40 points done in one sprint, you should get 120 points done in 3 sprints. Even the slightest thing can cause a team’s velocity to shift. A holiday, team member vacation, new additions to the team, and much more can cause the velocity to shift.

Comparing team velocities is a big no-no in my book. Teams tend to estimate differently from one another. Comparing team velocities has no value. Another common issue is when a team member’s performance is measured by velocity. An individual’s velocity is reached through some number crunching, and the number reached may not be what was expected. Both of these scenarios should throw up warning signals if you see them.

Alternatives

Story Carryover – instead of looking toward what your team has done, focus on what work has been hanging around. Sprints are meant to be filled with attainable goals. In a perfect world, the team would deliver all the work it committed to at the beginning of every sprint. That is rarely the case. You can make sure the story carryover is kept at a reasonable amount from sprint to sprint. This outcome is an attainable goal.

Steady Velocity – If you still have someone insistent on measuring velocity, you can always look at the consistency of the team’s velocity. Doing this is more to find issues your team might face that are not on the surface. You may find that the team has too many priorities, team members are being changed out too frequently, or something else entirely.

The attitude towards measuring velocity needs to change from making the team faster to finding where the team needs help.