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).
- When you’ll be able to deliver all user stories in the product backlog.
- How many story points will you be able to deliver by a certain date.
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 timing — to help us get better and better and speed up, compared only to ourselves.
Velocity is a problematic metric because it is easy to manipulate and often misused as an indicator of efficiency.
Don’t forget that:
- Velocity is that it conflates work done with planning accuracy.
- Velocity is that it does not take quality or priority into account. Velocity can be increased by neglecting good design, refactoring, coding standards, and technical debt.
- Velocity is that it is often misused as a measure of efficiency or team performance. Velocity is a metric of work done, not efficiency.
- Velocity can be increased by working overtime or adding team members, neither of which necessarily increase efficiency or performance.
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.
As on 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 — development environment
- Visibility — project transparency
- Directions — project objectives
- Traffic/driving rules — processes
- Destination — product