What is meant by Team Velocity?

Now that we have understood what a Story point is and why we should be using story points for our estimation, it is time we learnt another key Scrum topic – “Velocity”.

Velocity is a term that is very frequently used in Scrum Projects and to be fair, is very easy to understand. When you start working on an Agile project as the Scrum Master, you will be responsible to measure the velocity of your scrum team and hence it is very important that you understand this concept well. The purpose of this article is to do just that.

What is Velocity?

In physics Velocity refers to the speed at which an object is moving in a particular direction. Without Direction, we only have Speed which may not be as useful as when we know the Direction. The meaning of Velocity in Scrum is very close to what we know in Physics.

To put it simply – Velocity is simply a measure of how fast the scrum team is going towards achieving the product functionality or goal. We measure this at the end of every iteration and use the number to predict how much the team may be able to deliver in upcoming Iterations as well.

In real life projects, Velocity is nothing but the total of the Story Point Estimates of all the feature user stories the team was able to complete in the Sprint or Iteration under consideration.

Again, the emphasis here is on achieving product functionality because the team may be able to build a lot of things but if they do not contribute towards the product functionality that can be shipped out to customer, they do not count towards Velocity.

A simple example here would be bug-fixes on code. While the team is testing a user story, they may identify bugs in the code and would eventually fix them during the Sprint. As bug-fixing is part of the initial story point estimate that was given for the story, a fresh estimate is not required and hence this effort does not contribute to Velocity.

Are Work In Progress Stories Counted towards Velocity?

One of the biggest questions new Scrum masters have is; whether Work In Progress User Stories contribute toward Velocity. The Answer is “No”. let me explain…

Firstly, Scrum recommends that user stories be broken down into smaller/granular pieces that can be completed in a single Sprint or Iteration. If for some reason the team is unable to finish a certain user story, the partial completion of the user story does not contribute towards the Velocity because the story was not “Completed” and hence does not add any value to the Product as a whole.

You may be wondering what about the effort spent on that partially completed user story and why it did not contribute to the teams Velocity – are you?

Like I explained in the previous paragraph, Velocity is a measure of the usable or shippable functionality the team was able to produce in a sprint. Half-finished work items will not be counted towards the Sprint’s Velocity for the team.

On a related note, Scrum recommends that, at the end of each sprint, the team review such unfinished story with the product owner to decide whether it is worthwhile to continue work on the story or should they focus on any newer or higher priority user story.

Keeping Teams Velocity Clean

Sometimes, scrum teams pay a lot of attention to the velocity and try to do stories just to boost up the velocity. There could be activities the team does as part of their job (maybe code refactoring or environment maintenance etc) that don’t really count towards the teams velocity. A team that understands its purpose does not bother about these day to day activities while some scrum teams try to create user stories even for such routine activities just to boost up their velocity output for the iteration.

Any time we hear a team talk about including some work they've done toward the velocity being counted, it's a bad sign that something is amiss. Often this is the result of a culture that is overly focused on looking at velocity as proof the team is delivering stuff towards a release. Sometimes, this pressure for a high velocity comes from the team itself.

Setting a target velocity to aim for the team is a good idea but, achieving a velocity should not become the team's goal. The team's goal is to deliver incremental improvements to the product - PERIOD.