Agile velocity and story points
Velocity is the measure of how much work an agile team completes in a sprint, expressed in story points. It is the most useful planning input available to a Scrum team — and one of the most frequently misused metrics in agile practice. This guide explains what velocity measures, how to calculate it correctly, and how to use it productively.
What velocity measures
Velocity measures throughput — the number of story points a team completes to the Definition of Done in a single sprint. It captures the team's actual delivery capacity, including all the friction, interruptions, and overhead that raw capacity calculations miss.
Velocity does not measure individual productivity. It does not measure code quality. It does not measure whether the right things were built. It measures one thing: how many story points, measured on this team's scale, were completed in this sprint.
This specificity is both velocity's strength and its limitation. As a planning input for a single team working on a known codebase, it is highly reliable. As a comparison metric between teams, or as a measure of business value delivered, it is meaningless.
How to calculate sprint velocity
Sprint velocity is the total story points completed (to Definition of Done) in a sprint. Stories that are started but not finished do not count — partial credit undermines the metric's reliability.
Velocity = Σ (story points of completed stories) per sprint
Planning velocity — the number you use for sprint planning — is typically a rolling average of the last 3–5 sprints. This smooths out anomalous sprints (holidays, incidents, unusually easy or hard stories) and provides a more reliable baseline.
Rolling average velocity = (Sprint N + Sprint N-1 + Sprint N-2 + Sprint N-3) / 4
Do not use a single sprint's velocity for planning. One exceptional sprint (all simple stories, full team availability, no incidents) will inflate expectations; one difficult sprint will deflate them.
Using velocity for sprint planning
Velocity is the input that converts story points into capacity. Once you know your rolling average velocity, sprint planning becomes a simple matching exercise: select stories from the top of the backlog until the total story points approach, but do not exceed, the planning velocity.
- Plan at 80–90% of velocity: leave a buffer for unexpected work, code review overhead, and minor unplanned interruptions. Teams that plan at 100% of velocity consistently over-commit.
- Adjust for team availability: if the team is at 80% capacity this sprint (due to holidays or conferences), plan at 80% of your adjusted velocity.
- Update velocity every sprint: drop the oldest sprint from your rolling average and add the most recent one. Stale velocity data is worse than no data.
Release forecasting with velocity
Velocity enables release forecasting: given a known backlog size (in story points), when will the team finish it?
A simple forecast: count the total story points remaining in the backlog. Divide by rolling average velocity. The result is the number of sprints remaining. Multiply by sprint length to get elapsed calendar time.
Example: 200 points remaining ÷ 40 points/sprint average = 5 sprints ≈ 10 weeks for a 2-week sprint cycle.
This is a forecast, not a commitment. Variability in velocity, changing scope, and team changes all affect the actual delivery date. Present forecasts with a range (based on best-case and worst-case velocity scenarios) rather than a single date.
Range-based forecast: best case (velocity = 90th percentile of recent sprints), worst case (velocity = 10th percentile). The realistic completion window lies between these two dates.
Velocity anti-patterns to avoid
Velocity is useful only when it is not gamed. These practices destroy its reliability.
- Using velocity as a performance metric: when teams are rewarded for high velocity, estimates inflate. This is known as Goodhart's Law: "When a measure becomes a target, it ceases to be a good measure."
- Comparing velocity between teams: different teams calibrate their story point scales independently. A team completing 80 points per sprint is not twice as productive as a team completing 40 — they are simply using a different scale.
- Counting unfinished stories: partial velocity credit introduces arbitrary variability. Either the story is Done and gets counted, or it isn't and it doesn't.
- Expecting velocity to increase indefinitely: mature teams reach a stable velocity band. Constant pressure to increase velocity produces inflated estimates, quality shortcuts, and burnout — not genuine improvement.
Velocity FAQ
What is a good velocity for a Scrum team?
There is no universal "good" velocity. Velocity only has meaning relative to your own team's historical data. A team of 4 completing 25 points per sprint may be high-performing; a team of 8 completing 25 points may not be. Context is everything.
Why did our velocity drop suddenly?
Common causes: team composition change (new member still ramping up, experienced member leaving), sprint with unusually complex stories, increased interruption load (on-call, production incidents, meetings), or scope changes that removed completed work from the Definition of Done.
Should we estimate spikes in story points?
Spikes (time-boxed research tasks) are usually estimated in time rather than story points, and many teams exclude them from velocity calculations. If you include them, use a consistent approach and document it — mixing time-boxed and effort-based estimates creates velocity noise.
How long does it take for velocity to stabilise?
Most teams reach a stable velocity band within 4–6 sprints. The first two sprints are calibration data only. After sprint 4, the rolling average becomes a reliable planning input.
Estimate your sprint backlog with free online planning poker