How to Read Team Velocity Without Fooling Yourself
Almost every team plans off velocity: "we do about 30 points a sprint, so the 120 points left is four sprints." It's a reasonable starting point. It's also where a lot of confident, wrong forecasts come from — not because velocity is useless, but because of how it gets read. Three habits make the number lie, and they're easy to fix.
Trap 1: reading the average and ignoring the spread
"30 points a sprint" is a mean. The sprints behind it might be a tidy 28, 30, 31 — or a wild 12, 30, 48. Same average, completely different risk. If you plan off the average alone, you're implicitly promising the good sprints will keep showing up. The honest read looks at the spread: how consistent has the team actually been? A wide spread doesn't mean don't forecast — it means the forecast needs a range, not a single number.
Trap 2: treating velocity as capacity
This is the big one. Velocity is output — how much the team delivered when everyone was there. Capacity is availability — how much they can do next sprint, given who's actually around. They're not the same, and next sprint isn't last quarter. Two people on leave, a new hire ramping, someone pulled onto another project — none of that shows up in the velocity number, but all of it changes what the team can do. Plan off velocity adjusted for the capacity you'll actually have, not off velocity as if the roster never changes.
Trap 3: reading team velocity when the problem is per-person
A team velocity of 30 can hide a lot. Maybe two people carry most of it and a third is blocked every sprint. The team number looks stable while the distribution underneath is fragile — lose one person and "30" was never real. Looking at velocity per person, not just per team, tells you how much of your throughput depends on who, and where the single points of failure are.
What to actually watch
- The trend, not the last number. Is velocity improving, stable, or declining over the last several sprints? A single hot sprint isn't a new baseline.
- The consistency. A steady 28–32 is worth more for planning than a volatile 15–45 with the same average, because you can trust it further out.
- Effectiveness. How much of what the team commits does it actually deliver? A team that reliably finishes 80% of its commitment should be planned at 80%, not 100%.
- Velocity as an input, not the answer. Velocity is one signal that feeds a capacity-aware forecast. On its own it's a rear-view mirror; combined with real capacity and dependencies, it becomes a forecast you can defend.
Project Commander shows your velocity history with its trend and rolling average, tracks it per person as well as per team, measures the effectiveness factor (delivered vs. committed) from your own sprints — and, crucially, uses velocity as one input to a capacity-aware forecast rather than the whole story. So you get the honest read, not the flattering one.
See your real velocity picture
Project Commander is a free Forge app on the Atlassian Marketplace — it installs in about two minutes and reads a live Jira project right away. Or try the interactive demo first, no install needed.