What is Velocity?
The truth is: Velocity is Velocity.
And Velocity is measured..as velocity is.
How do you measure your velocity while driving? (Considering the velocity counter is broken) :)
You are driving for the last 2 hours, you’ve done 160km until now, so you know your average velocity is 80km per hour.
If your final destiny is about 200km away from your starting point:
- You know you will likely get there in 30minutes or
- If you stop now you have already gone through 160km or
- If you need to fuel up and stop in 15minutes, you can say you’ve done 180km
Same goes with projects:
- Team velocity is the rate at which a team delivers Stories from Product backlog.
If you know your velocity, you’ll have an idea on:
- How much value you’ve delivered until now (in Story points and Done US)
- When you’ll be able to deliver all US in the Product backlog
- How much SP will you be able to deliver by a certain date
How do we calculate velocity?
Simple! We do some simple math:
Scenario : Our team delivers 3 US. The Sum of their Story points is equal to 20.
If next iteration our team delivers 30SPs , then our Average velocity is 25.
(20SP+30sp) divided by 2 Iterations = 25SP
Fig1: Awesome hand-made Velocity chart
Velocity is the number of story points completed by a team in a iteration.
Why do we need it?
- to predict how much scope can be delivered by a specific date or
- to predict a date for a fixed amount of scope to be delivered
- to understand our limits while defining the amount of scope we will commit for a sprint
What influences my velocity?
As in a car trip, there are things that may influence our velocity
- Road Blocks – aka Impediments
- Fuel – aka motivation, what drives us :)
- Experience from driver – knowledge/expertise/Competence developer
- Car conditions – Dev environment
- Road visibility – Project transparency
- Road Directions – project objectives
- Traffic/driving Rules- Processes
- Destiny – Product
So think, if all those things are in a bad shape, or without a proper definition, visibility, your velocity decreases. Same goes on with projects.
Can I consider incomplete US?
No, you shouldn’t.
Incomplete is Undone. Velocity is about Done US delivered.
Some reasons why you shouldn’t do it:
- We can’t really figure out how much is ready and how much is not, it will be a wild guess
- We may be lead by a sense of false accuracy and precision, given by the use of fractional numbers
- Incomplete means the US has still not value for the customer.
What should I do then?
Break User stories in smaller ones. This way it will be easier for you to add them in a sprint and manage to deliver them.
Teams and their velocity
Should bugs and maintenance be considered as Velocity?
Yes if you estimate their size in story points.
It’s work delivered right? Although with no direct value to customer, it’s 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!
Should I compare team’s velocity?
Well, because we work with Story points. As such we work with relative estimation – We compare User Stories with each other, having as basis a reference User story the team picked up.
The Story Points of that reference US can be anything. A team can say that the reference-User Story is equal to 400SP or equal to 2SP… it can be anything! It actually doesnt matter because we work with RELATIVE ESTIMATES.
The goal is not the number itself – the goal here is to use this US as a reference and use it to estimate others by comparison.
So, how could we compare velocity in this case?
Team A is delivering 800SP and Team B is delivering 30SP, 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 if we were racing against each other, Velocity is used to help us improving our timing – to help us getting better and better and speed up.
What about teams working with same Product Backlog?
Well, this is then a different case:
It is nonsense to have teams using different comparing units for the US in same product Backlog. We use SP 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 1 team working in a backlog and they use different size for US, we won’t be able to do this predictions.
In this case, teams must get together and define a Reference US. After they should decide what’s the size of that Us in SP. Then, on every refinement, the teams, or their representatives, will estimate having as basis the same US and same Size for comparison.
Then, in this case, can I compare teams?
Nope. Why would you? Maybe some are delivering less SP because those US were not well estimated comparing 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. Most probably you’ll see there are several impediments you need to take care.
Each Car has its own characteristics: we need to get the best from each..and know that if we push it to 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 sustainable pace and keep them moving. Driving our company further.
Material for you to read more about it
Mike Cohn’s Blog: http://blog.mountaingoatsoftware.com/tag/velocity
User stories applied Mike cohn
Agile Game Development with Scrum
Scrum and XP from the Trenches – Henrik Kniberg although he refers velocity is The amount os DP the team _believes_ they will deliver – which is not exactly what we consider – we consider the amount our delivers effectively.