Episode 5 : Velocity in Agile

“Velocity” is a very common metric used by IT teams following Agile.

In this episode we will try to understand what Velocity is, how to measure it, its benefits, and the problems it can cause if not used in a correct way.

Velocity: The number of Story points delivered by a team in a Sprint is called its Velocity.

If someone asks about team’s Velocity, generally we consider the story points we have been delivering for the last few sprints (3 – 6 Sprints) to come up with a number.

During the Sprint Planning, when we are coming up with the Sprint backlog (Scope for the Sprint), Velocity is the major metric we consider, and we take so many Story Points of work for the upcoming Sprint.

Is Velocity the Pure Mathematical Average?

Scenario 1: Let us say the Velocity of the team for the last 3 Sprints is 28, 30 and 26 Story Points.

In this case the average velocity is (28+30+26)/3 = 28. We can safely say that our Velocity is around 28 and we can consider taking 28 Story Points for the upcoming Sprint if we have full capacity.

Scenario 2: Let us say the Velocity of the team for the last 3 Sprints is 28, 10 and 20 Story Points.

In this case the average velocity is (28+10+20)/3=19.3. Does this mean we should take only 19 Story Points for the upcoming Sprint? The obvious answer is NO.

We need to consider the reasons for Velocity being low during that period. It is possible that there were some holidays (Like Christmas) or some team members gone on holiday. Pure mathematical average will not work here.

The average of the last few Sprints gives us some idea, on top of it we must consider the context, the capacity availability and use our common sense to come up with number for the upcoming Sprint.

Can Velocities of different Teams be compared?

In my previous episodes (Episode 3 and Episode 4), we have understood how to define a reference story, assign story points to that story and all new stories to be compared to this reference story in terms Volume, complexity, Known and unknown things about the story.

While assigning story points to a reference story, different teams might assign different story points. For a similar story one team might assign “5” story points, the second team “3” and third one may be “8” story points.

As teams will have different references, obviously the story points they give to new stories will also differ. So, we just cannot compare velocities of different teams.

Usage of Velocity

Velocity will help teams understand the amount of work they have been doing in the previous sprints and accordingly they can plan the upcoming Sprints. It will also help the Product Owner to understand teams’ capability and give the predictability to the stakeholders accordingly.

Is Velocity improvement by x% every Sprint/quarter a good KPI?

We see in many organizations that higher management coming up with this KPI like the teams Velocity must be improved by x% every Sprint or every quarter.

For me, this is not a good KPI as teams will feel pressurized and in turn will make more mistakes to meet the numbers. Initially everything will appear green on paper/graphs but eventually we end up spending more time and effort to fix the mistakes. Also, people are smart enough to cook up the numbers and give what management want. Self-organizing teams anyway will improve their velocity over a period.

Instead, we must look up other Value metrics like Cycle time, Customer satisfaction and so on.

Anti Pattern: Management using Velocity as the metric and asking teams to improve by X% every Sprint and comparing Velocities of different teams.