Velocity

How to Calculate and Use Velocity to Help Your Team and Your Projects

6 February 2014


What is velocity?

The truth is: Velocity is velocity. And velocity is measured . . . as velocity is.

How do you measure your velocity while driving? (Imagine the speedometer is broken.) You've been driving for the last two hours, you've gone 160 kilometers, so you know your average velocity is 80 km per hour.

If your final destiny is about 200 km away from your starting point:
  • You know you will likely get there in 30 minutes, or
  • If you stop now you have already gone 160 km, or
  • If you need to stop and fuel up in 15 minutes, you can say you've done 180 km.
The same goes for projects: Team velocity is the rate at which a team delivers stories from the product backlog. If you know your velocity, you'll have an idea about:
  • How much value you've delivered until now (in story points and done user stories), and
  • When you'll be able to deliver all user stories in the product backlog, and
  • How many story points will you be able to deliver by a certain date.

How do we calculate velocity?

Simple! We do some basic math.

Scenario: Our team delivers 3 user stories. The sum of the story points equals 20. Our velocity is then 20.

If, in the next iteration, our team delivers 30 story points, then our average velocity is 25, or (20 SP + 30 SP) divided by 2 iterations = 25 SP.

Figure 1: Awesome handmade velocity chart

Velocity is the number of story points completed by a team in an iteration.

Why do we need it?

We need velocity to:
  • Predict how much scope can be delivered by a specific date
  • Predict a date for a fixed amount of scope to be delivered
  • Understand our limits while defining the amount of scope we will commit for a sprint

What influences velocity?

As in a car trip, there are factors that may influence our velocity:
  • Roadblocks -- aka impediments
  • Fuel -- motivation, what drives us
  • Driver experience -- knowledge/expertise/competence developer
  • Car conditions -- dev environment
  • Visibility -- project transparency
  • Directions -- project objectives
  • Traffic/driving rules -- processes
  • Destination -- product
So think: If all those things are in bad shape, or without proper definition, then your velocity decreases. The same applies to projects.

Can I count in an incomplete user story?

No, you shouldn't. Incomplete is undone. Velocity is about finished, delivered user stories. Here are some reasons why you shouldn't count incomplete user stories:
  • We can't really figure out how much is ready and how much is not; it will be a wild guess.
  • We may be led by a false sense of accuracy, due to the use of fractional numbers.
  • Incomplete means the user story still has no value for the customer.

So what should I do with those user stories?

Break the user stories into smaller ones. That way it will be easier for you to add them to a sprint and manage to deliver them.

Teams and their velocity

Should bugs and maintenance be considered in velocity estimation?

Yes, if you estimate their size in story points. It's work delivered, right? Although with no direct value to the customer, this work is indirectly associated with value delivered. The proper way to handle this is: Don't create bugs(!). Use zero-bugs & prio1-fix-bugs policies. Whenever a bug pops up, finish it off!

Should I compare the velocity of different teams?

No.

Why not? Well, because we work with story points. Therefore we work with relative estimation; we compare user stories with each other, having as our basis a reference user story that the team picked up. The story points of that reference user story could be anything. A team could say that the reference user story is equal to 400 SP or equal to 2 SP. It actually doesn't matter, because we work with relative estimates.

The goal is not the number itself -- the goal is to use this user story as a reference so we can estimate other user stories by comparison.

So, how would we compare velocity in this case?

Team A is delivering 800 SP and Team B is delivering 30 SP. Does this mean A is better than B?

I don't know! And I don't care. Each team is comparable only to itself. Velocity is not used as a measure as if we were racing against each other. Velocity is used to help us improve our own timing -- to help us get better and better and speed up, compared only to ourselves.

What about teams working with the same product backlog?

This is a different case. It is nonsense to have teams using different units of comparison for the user stories in the same product backlog. We use story points to predict how much scope we'll be able to deliver by a certain date, or to predict when we may be able to deliver the scope. So if we have more than one team working on a backlog item and they use different sizes for the user story, we won't be able to make this prediction.

In this case, teams must get together and define a reference user story. Afterward they should decide on the size of that user story in story points. Then, in every refinement, the teams (or their representatives) will estimate, using the same user story and the same size for comparison.

Then, in this case, can I compare teams?

Nope. Why would you? Maybe some are delivering fewer story points because those user stories were not well estimated compared to others. Or maybe that team is helping other teams or paying more attention to testing, refactoring, coding standards. . . . We don't know, do we? You should compare a team with itself, and dig out why the team is slowing down (if it is). Probably you'll see there are several impediments you need to take care of.

Each car has its own characteristics. We need to get the best from each, knowing that if we push too hard, we will probably break the engine.

Help teams excel, don't punish them.

Humans are humans, and we are (gladly) different from each other. You'll always have teams performing differently from each other -- and that's not necessarily bad. We just need to find out each team's own sustainable pace and keep them moving, driving our company further.


Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.



Article Rating

Current rating: 4.6 (5 ratings)

Comments

Kapil Dhawan, CSM,CSPO, 2/6/2014 11:21:11 PM
Nice especially comparison between Project and Car.

I have always found this trouble of giving a ball park figure on the basis of high level requirements without team in place, user stories etc. Have you also come across this ever. If yes, how do you handle it.
Elmar Jobs, CSP,CSM, 2/8/2014 6:04:01 AM
Very good article about velocity, especially the part about "teams and their velocity". Just a few comments/additions:

When using velocity to predict the future one should always keep in mind that it is a mean value with a variance attached. What does that mean?

* Never look at too few sprints to calculate velocity when trying to estimate the delivery date.
* Never take the estimate too serious, as velocity might vary during the next sprints. Very good teams might maintain a constant velocity, but even then it is dangerous to rely to much on firm delivery dates.

What you mention about incomplete stories is very important in my opinion. Only add story points for complete stories (according to Definition of Done) to the sprint velocity. It might even happen that the story will never be finished because the PO decides that its time has passed. Furthermore, velocity must not be used for employee/team assessments. There is no need for the team to prove that they worked hard.

Regarding the question whether bugs and maintenance should be taken into account I am not sure whether that is the best way. Bugs are incomplete stories that only have been identified too late (after the sprint was finished). Therefore the team has to heal this as soon as possible, and the story points are already "earned". To be a bit more pragmatic: if the bug is serious (feature cannot be released), it has to be fixed immediately for zero story points. If it is not that serious, it becomes a normal story in the product backlog.
Glauber Queiroz de Oliveira, CSM, 2/17/2014 8:43:33 AM
Great article Catia! Congrats!
Catia Oliveira, CSP,CSM,CSPO, 2/18/2014 7:32:57 AM
Hi :)) sorry late responses!

@kapil yes! i think you are now talking about estimations right? Either way, if all you have a big picture of what needs to be done, then all you can do is give a big picture of the size of that work. I use Specification by example technique (see Gojko Adzic book) to work out in more depth what needs to be done in a specific Story. After doing this story preparation then the team is in a better place to estimate things. Hope this helps! :)
Catia Oliveira, CSP,CSM,CSPO, 2/18/2014 7:39:39 AM
Hi :)
@Elmar yes i totally agree! :) Bugs are very tricky.. I also think that teams should be able to use a zero-bugs policy as much as possible and whenever a bug pops-up: fix it. But unfortunately I've been in some teams where this is not possible (for several reasons) and so the bugs accumulate in a different backlog. Then when the team is able to fix bugs, everyone is asking why velocity dropped.. everyone then puts pressure on team and everyone things they have to do something to increase productivity again.. so that is why i suggest that if you cannot have a zero-bugs policy or fix it as soon as you found it, then as much as possible give it a value and consider it in you velocity.. this way you are taking some pressure out of the team. :) makes sense? I know it may not seem very orthodox.. but truth is that in daily life things happen in a different way and sometimes it's very difficult to have all things and people and ways of work in place and neat and clear.. so we have to find ways to slowly make things change, and protect those who normally get the worse out of it.
Catia Oliveira, CSP,CSM,CSPO, 2/18/2014 7:40:30 AM
@glauber Thanks! :)) It's good to know, that's what keeps us writing and sharing! :) thank you for letting me know i was useful ;)
Philipp Flenker, CSD,CSPO, 2/20/2014 4:59:00 AM
Nice article! I tend to look at the bugs as roadblocks or detours and thus do not count them into the velocity. Features and Stories are planned, as you would plan a long trip by car. Bugs are unplanned detours from your original road. Suppose you want to go from A to B. , but your bugs force you to take a detour to C and also to D. Including bugs into the velocity measures not only how fast you get from A to B, but also how fast you take the detours, and more detours will not be reflected in your velocity. In other words: If you go 60 mph straight from A to B it is slower, but better than going 120 mph from A via C,D,E,F and G to B. Even though it frequently leads to discussions, this is why I do not include Bugs into the velocity.
Seshadri Thaggikuppe, CSM, 3/14/2014 1:40:48 PM
A more correct defition of Velocity is:
Velocity is the rate of story points completed by a team.

It is expressed as a ratio of story points completed so far in iterations divided by the number of iterations.

You can also graph the velocity line on the same chart to show visually if the velocity trend (trending upwards or downwards or staying the same).
Sudha Bhat, CSM, 3/16/2014 10:52:40 AM
Nice article! Especially the discussion on whether bugs should be considered for calculating team's velocity is interesting.
Warren Marshall, CSPO, 3/16/2014 5:52:06 PM
Having been a product owner for quite a while now, and recognising that velocity is SUPPOSED to be based only on completed stories, I've come to the conclusion that velocity should be adjusted for SOME incomplete stories, even though they have no value to me as they are incomplete. The reason for this is simple enough. I've compared velocities retrospectively, ignoring incomplete stories and including those incomplete stories, and the actual velocity moving forward (also calculated retrospectively) lay somewhere in between. I can go into details about why I believe this is the case, but the most important thing is that I was able to "guess" which incomplete stories should be complete, and the resulting velocity was almost spot on!

Of course the assumption is that the product owner is knowledgeable enough to makle that sort of value judgement, but, if he isn't, then why is he the product owner?
Warren Marshall, CSPO, 3/16/2014 6:26:16 PM
Having been a product owner for quite a while now, and recognising that velocity is SUPPOSED to be based only on completed stories, I've come to the conclusion that velocity should be adjusted for SOME incomplete stories, even though they have no value to me as they are incomplete. The reason for this is simple enough. I've compared velocities retrospectively, ignoring incomplete stories and including those incomplete stories, and the actual velocity moving forward (also calculated retrospectively) lay somewhere in between. I can go into details about why I believe this is the case, but the most important thing is that I was able to "guess" which incomplete stories should be complete, and the resulting velocity was almost spot on!

Of course the assumption is that the product owner is knowledgeable enough to makle that sort of value judgement, but, if he isn't, then why is he the product owner?
Chandrasekaran Janakiraman, CSM, 3/17/2014 6:21:53 AM
@Catia - Thanks for this write-up.A very neat explanation on Velocity and importance.On the topic of bug fixes - I have a different opinion on the approach that you suggested.Unless we see Velocity go down in an iteration due to work on bug fixes, may be we are missing an opportunity to address a potential process improvement...? One approach that worked well in my project was to triage the "non-serious" bugs and get PO approval for prioitizing them in iterations.Also we "reserve" team capacity to handle bug fixes upfront during planning meetings and try to progressively move forward based on Retro outputs in reducing this "reserve" to pull functional stories...
Chandrasekaran Janakiraman, CSM, 3/17/2014 8:26:33 AM
@Catia - Thanks for this write-up.A very neat explanation on Velocity and importance.On the topic of bug fixes - I have a different opinion on the approach that you suggested.Unless we see Velocity go down in an iteration due to work on bug fixes, may be we are missing an opportunity to address a potential process improvement...? One approach that worked well in my project was to triage the "non-serious" bugs and get PO approval for prioitizing them in iterations.Also we "reserve" team capacity to handle bug fixes upfront during planning meetings and try to progressively move forward based on Retro outputs in reducing this "reserve" to pull functional stories...
ATUL KUMAR VERMA, CSM, 7/3/2014 6:41:34 AM
@Catia - Nice Article and liked the way you explained everything...

I am very new to scrum and want to know what are the ways to calculate the expected velocity before very 1st Sprint???

Will it be only depend upon the expertise of team who is estimating it on the basis of their experience or is there are any other ways too???

You must Login or Signup to comment.