Velocity, a mandatory indicator in Scrum?

A question often arises in Scrum teams: velocity, a mandatory indicator in Scrum? I have always been surprised to see the importance of this often not used indicator.

What’s velocity?

For those who do not know velocity, I’ll explain quickly what velocity is; but this article will not be interesting if you have never handled this indicator.

Velocity is a very used indicator in Scrum to track a team’s work across multiple sprints. Velocity is used in France to talk about the sum of story points of the finished items at the end of the sprint.

We will take a simple example to understand. Here is the state of 4 items in Sprint closure:

• 1 item with 3 in story point in progress
• 1 item with 1 in story point in Done
• 2 items with 3 in story point in Done
• 1 item with 5 in story point in Done

The velocity of the sprint that ends will be 1 + 3 + 3  + 5 = 12. Indeed it is very simple to calculate.

What is velocity for?

Here is an example of a velocity chart that compares the velocity that the team engaged in at the start of the sprint and that was ultimately achieved (graph from Jira).

We can also compare the velocities between them by comparing the green curves. We can see the evolution of the team work or to make predictability.

Unfortunately, because I am not familiar with these practices (I am opposed), these velocity indicators centralized on a tool allow some companies to make comparisons between projects or even to trigger action plans.

Stop misuse

Wait for a constant evolution (rising) of velocity

Some companies expect that each team to constantly improve its velocity from sprint to sprint.

It is not uncommon for the velocity of the first 3 sprints to be real progress for several reasons:

• The team gets to know each other
• The sprint 0 (or creation of the technical base) is often disturbing at the start of a project

But after 4 sprints, it’s rare to compare the velocity from one sprint to another. It happens sometimes in large companies that the project is totally blocked by external elements but it’s a very small minority of cases.

Those who do not put story points to bugs can indeed see an interest in comparing velocities because they are slightly related to the business value. But I think it’s dangerous to do this practice : story points are not business values.

However, deciding to question the team in case of velocity drop does not make sense because many things can lower it:

• the story point is not a perfect estimate
• the team is affected by a flu
• a seminar took place
• a change of leader of a team (which can affect the story point)
• the increment of tiny patches (design, text adjustment, …)

There are many cases that may indicate that a drop in velocity does not bring any interesting information. Moreover, this does not necessarily indicate a decrease in productivity.

In this case and if the company is very “indicator”, I still prefer to try to convince the manager that’s not a good practice; I will try to coach the manager for them to understand that the velocity is not the productivity of the team.

Comparing a velocity from one project to another: a nonsense

Unfortunately, we still see companies compare the velocity from one team to another. Obviously this practice can only bring problems if the team feels obliged to have to prove something (sometimes a tempting bonus to the key).

Teams sometimes do over-estimating requests, thinking they align with others presented as more productive. I let you imagine the interest of having this type of practices within companies.

It is likely that the velocity will eventually increase while productivity is declining.

Why is velocity rarely useful?

When I look at the implementation of Scrum in many teams, I see a lot of teams doing estimation without real goal:

• I estimate to have a velocity
• my velocity serves me to …… nothing

If you do not do a real predictability calculation or your velocity allows you to make unnecessary comparisons, I suggest you stop this  practice ; it will just be a waste of time.

Let’s use the time we have to really offer it to team productivity.

Maintain velocity curves, estimate tasks, keep nice graphs related to velocity on the walls are wasted time if velocity is not used.

Conclusion velocity

Velocity is an indicator to use only if it really serves you; don’t use it just because it seems to be a mandatory. Analyze the situation of your teams and check that this “velocity” really makes sense.

Do you really use it or do you follow it only because the management say you it’s a mandatory?