Sprint Velocity Explained (and How Not to Abuse It)
How velocity is calculated, how many sprints before the number means anything, why it must never become a target, and how to forecast with an honest range.
What the number actually measures
Velocity is the total story points attached to items that met the Definition of Done within a single sprint. Nothing else counts. Work that is ninety percent complete contributes zero, which feels harsh but is the entire reason the measure stays honest.
Because story points are a relative unit invented by one team for its own use, velocity is meaningful inside that team and meaningless outside it. A team averaging 30 is not more productive than one averaging 18; they simply calibrated their scale differently.
Treat it as a planning input, not an achievement. It answers 'roughly how much can we take on next sprint' and nothing more ambitious than that.
How to calculate it properly
Sum the points of completed items for each of the last three to five sprints, then average them. Three sprints is the minimum for a rough signal; five gives a range you can plan against with some confidence.
Exclude sprints distorted by unusual events — a public holiday week, a production incident that consumed four days, a team that changed half its members. Including them does not make the average more honest, it makes it noisier.
Reset your expectations whenever team composition changes materially. Velocity is a property of a specific group of people working together, and it does not transfer with a reorganisation.
Why it must never become a target
The moment leadership asks a team to raise velocity, estimates inflate. Nothing changes in throughput; only the labels change. This is Goodhart's law with a burndown chart attached, and it happens quickly and quietly.
The damage is worse than the wasted metric. Once teams learn that estimates are a performance instrument, refinement conversations stop being about shared understanding and start being about negotiation, which is where genuine risk discussion goes to die.
If you want a productivity signal, look at cycle time and delivered outcomes. Both are far harder to game and far more informative.
Forecasting with a range
Take the lowest and the highest velocity from your last five sprints and divide the remaining backlog points by each. You now have a pessimistic and an optimistic sprint count, and communicating both is more honest than a single confident number.
Update the forecast every sprint rather than defending the original. Stakeholders tolerate a moving forecast far better than a fixed promise that fails at the last minute.
Pair the range with an explicit assumption list: no scope additions, stable team, no unplanned support load. When the forecast slips, you can point to which assumption broke instead of arguing about effort.
Frequently Asked Questions
- How many sprints before velocity is reliable?
- Three at an absolute minimum, five for a usable planning range, and only when the team's composition has stayed stable across those sprints.
- Can velocity be compared between teams?
- No. Story points are calibrated locally, so cross-team comparison measures estimating habits rather than output, and it damages trust quickly.
- Should partially finished stories count?
- No. Only work meeting the Definition of Done counts. Partial credit removes the pressure to finish, which is the main behaviour the measure is meant to encourage.
Published by AgilePro.info under our Editorial Policy. Guidance is based on established delivery practice and is general information, not professional advice for a specific project.