A VP I worked with once put two teams' velocities on the same slide. Team A: 52. Team B: 28. He didn't say anything mean. He just let the numbers sit there, side by side, and looked at Team B's lead.
Within two sprints, Team B was doing 50. Nothing shipped faster. They'd just learned that an 8 could be a 13 if you said it with confidence.
Here's the thing nobody tells you about velocity: it's not a productivity metric, a commitment, or a number you can compare across teams. It's a forecast with the error bars sawed off. And almost everyone reports it as if the error bars were never there.
I've spent the last few years building agile estimation tools and watching teams do this to themselves. The pattern is always the same. The number is fine. What people do with the number is where it goes wrong.
The three jobs people give velocity that it cannot do
Velocity has exactly one honest use: a rough sense of how much your team tends to get done, so you can plan the next sprint and forecast the rough shape of a release. That's it. Every problem I've seen comes from asking it to do one of these three things instead.
Job 1: be a single delivery date. Someone asks "when's it done?", you divide the backlog by your average velocity, and you say a number. I did this once. Backlog of 200 points, average velocity of 25, so I wrote "8 sprints" on a whiteboard in front of a stakeholder. We finished on sprint 11. I spent a quarter explaining the gap. The number wasn't wrong, exactly. It was just one outcome out of a distribution I'd flattened into a point because a point felt more professional.
Job 2: be a scoreboard. See the VP above. The moment velocity leaves the team and goes onto a comparison slide, it stops measuring work and starts measuring how brave people feel about inflating estimates.
Job 3: be a target. "You did 30 last sprint, commit to 30." This is Goodhart's law with a Jira board. Make velocity the goal and it climbs, reliably, while delivery stays exactly where it was.
Why the single number lies
Take a real-looking run of six sprints: 22, 28, 19, 31, 24, 26.
The average is 25. But you never delivered 25. Your actual spread runs from 19 to 31. That's a 60% swing between your worst and best sprint, and it's completely normal. Sprints have holidays, outages, that one ticket that turns out to be a three-week archaeology dig.
So when you forecast with "25", you're not lying on purpose. You're just reporting the mean of a distribution and dropping every other fact about it. A team that runs 24, 25, 26 and a team that runs 12, 38, 25 have the same average and wildly different futures. The average can't tell them apart. The variance can.
Forecast in ranges, like you actually believe the uncertainty
The fix isn't complicated and it isn't Monte Carlo (though Monte Carlo is great and I'll get to it). The fix is to stop saying one number.
The cheapest honest version is three forecasts. Take your history and run the maths three times:
- Conservative: average of your three slowest sprints. For the run above, ~22 → about 10 sprints for a 200-point backlog.
- Likely: overall average, 25 → 8 sprints.
- Optimistic: average of your three fastest, ~28 → about 7 sprints.
Now you tell the stakeholder "7 to 10 sprints, most likely 8." That sentence has survived contact with reality more often than any single number I've ever given. It also does something political: it makes the uncertainty theirs to manage too, instead of a promise they get to hold you to.
If you want to go one step further, Monte Carlo simulation samples thousands of futures from your real sprint history and hands you percentiles. "85% chance we're done by sprint 9" is a far stronger claim than any average, because it's the only one that actually tells you how confident to be. You don't need a single point estimate. You need a distribution, and you've had one this whole time. You just kept throwing it away.
Where the velocity skeptics are right
I'm not going to pretend the "velocity is useless" crowd is arguing in bad faith, because on several points they're correct.
For a very small, very stable team, with one tracker and no PMs, the average really is fine. The variance is low, everyone already knows the score, and three-point forecasting is ceremony for an audience that doesn't exist.
They're also right that points are a weird, abstract currency that invites exactly the misuse above. Plenty of teams are better off counting throughput (how many items they finish per sprint) and measuring cycle time (how long an item takes start to done) with real timestamps instead of arguing about whether something is a 5 or an 8. Those metrics can't be inflated by sizing harder, which is their whole appeal.
The honest position isn't "velocity good" or "velocity bad." It's that velocity is a flashlight, not a speedometer. Point it at the work and it helps you see. Point it at people and it stops telling the truth.
How I report it now
After the whiteboard incident, my rules got simple:
- Never quote a velocity number to anyone outside the team without a range attached.
- Average over at least six sprints, and watch the trend, not any single sprint.
- Re-baseline after the team changes. Old velocity doesn't transfer to a team with two new people.
- If a number is going on a slide that compares teams, it doesn't go on the slide.
The product bit, scoped honestly
I work on Kollabe, so apply the appropriate grain of salt. The patterns above generalise; if your tools do these differently, swap in the equivalents.
Two things are worth knowing. First, we deliberately don't ship in-app velocity dashboards or burndown charts, because a dashboard that auto-tracks velocity over time is the fastest way to turn it into the scoreboard I keep warning about. Second, the part we do obsess over is the estimation conversation itself. Planning poker exists because the value of estimating was never the points, it was the argument that happens when one person says 3 and another says 13 and you find out they pictured completely different work.
If you just want the numbers crunched without building a spreadsheet, there's a free Sprint Velocity Calculator that takes your last few sprints and gives you the average, the realistic range, a consistency score, and a rough backlog forecast. No login, no tracking, paste and go. It's the range-thinking from this post without the arithmetic.
The rule of thumb to steal
Before you say a velocity number out loud, ask one question: am I using this to plan, or to judge?
If you're planning, attach a range and carry on. If you're judging, a team or a person or a quarter, put the number down and walk away. It will not tell you what you think it's telling you, and the team will adjust its estimates faster than you can adjust your slide.
Velocity was never the problem. Single numbers are. Give the uncertainty back to the people who need to plan around it, and the metric quietly goes back to being useful.
If you want the lazy version of all this, run a few sprints through the calculator and look at the range it gives you next to the average you'd have quoted. The gap between those two numbers is the size of the lie you were about to tell. Then go forecast like you believe it.
Top comments (0)