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 do we calculate velocity?
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.
Simple! We do some basic math.
: 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:
What influences velocity?
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
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:
So what should I do with those 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.
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?
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.