Short answer: velocity is a historical measure of how much work a team completed in a Sprint. It is used to forecast a range of future outcomes. It is not a productivity metric, a target or a performance measure.
Velocity is a forecasting input, not a commitment
Velocity reflects what a team has already completed, not what it promises to deliver next. It supports forecasting of possible future outcomes. It does not lock in dates or scope. Most misuse begins when velocity is treated as a commitment instead of a learning signal.
In Agile estimation isn't broken we argued that the problem with estimation is not the technique but the thinking behind it. We explored the cone of uncertainty and why forecasting is not about precision. The more you do not know, the less predictable things become.
Now let's talk about velocity. It is one of the most misunderstood numbers in product development.
It is not the only option for planning and forecasting. It might not even be the best. But it is one of the most common we see. Before exploring other ways to forecast and plan, we need to be clear about what velocity is and what it is not.
Velocity is not a target. It is a result.
Velocity reflects how much work a team completed in a Sprint, usually measured in story points. That is it.
It is not speed. It is not productivity. It is not something to hit. It is something to notice.
Used well, it helps a team answer questions like:
- What do we usually finish?
- Are we consistent?
- What might we forecast next?
That is all. And that can be enough, if you approach it the right way.
Where it goes wrong
Teams often say velocity reflects past performance. But then they:
- Treat the average like a promise.
- Expect consistency in an inconsistent world.
- Use it to compare teams.
- Tie it to bonuses.
- Forget what it is actually for.
Suddenly velocity becomes a target. Once that happens, estimates get inflated, forecasts get rigid and trust takes a hit.
Yes, there are better ways to plan. But we always meet teams where they are, not where we wish they were. Once the mindset shifts, better approaches usually follow.
Let's make it real
Two towns, one hundred and forty miles apart. The speed limit is seventy miles an hour.
So the journey takes two hours?
Of course not. You are not driving at seventy the whole way. There is traffic. Roadworks. Time of day. Weather. Roundabouts. Delays.
When you plan a trip you do not give an exact time. You give a range based on what you know.
That is forecasting. That is the cone of uncertainty. And the same mindset applies to product development.
Old sat nav versus live traffic
A modern sat nav gives you an arrival time based on what is happening right now. It adjusts constantly. It never promises a fixed arrival time.
The old ones just used distance and speed.
One helps you make better decisions. The other gives you a false sense of control.
If your team uses velocity as a fixed number, you are running with an outdated sat nav. Forecasts should adjust as you learn more.
Velocity becomes useful again when you use a range
If you use velocity to forecast, do not just take the average. Use a range:
- Best case
- Typical case
- Worst case
That gives you flexibility and realism. It turns velocity into a conversation instead of a score.
Understanding velocity in practice
Velocity is mostly used by teams that estimate with relative sizing, usually story points.
It is not a perfect approach. But it gives a team a shared way to talk about complexity and to track how much it finishes each Sprint.
When we support teams we often use this sketch to reset how people think about velocity.
Velocity is just a result. It is not a target, not a promise, not speed. It reflects what got done, not what was started. Only completed work counts. That is what matters.
We also remind teams not to fixate on the average. Instead we ask:
- What was your lowest Sprint velocity?
- What was your average?
- What was your highest?
That range says more than any single number. It shows variability and uncertainty. How that feeds a forecast is the subject of the next post in the series.
There are more powerful ways to plan. Not every team is ready for them yet, and that is OK.
We meet teams where they are, not where we want them to be. Velocity is what many teams use, so we help them use it well. That is the reason for this post: not to promote velocity, but to explain it, ground it, and help teams move forward with the right mindset.
One last thing
Velocity is not perfect. But for many teams it is a step towards better planning and more honest conversations.
Used well, it builds trust. Used poorly, it creates waste.
The number is not the point. The thinking is.