Sprint Velocity measures the amount of work a development team completes per sprint, typically in story points. Use recent comparable sprints alongside upcoming availability and scope. The formula is Velocity = Total Story Points Completed / Number of Sprints. Variation in completed points describes the history; it does not measure team maturity. PM Toolkit's free velocity calculator helps product managers plan sprint capacity with multi-sprint tracking with running average, variance analysis, and capacity forecasting.
Ask Claude, Cursor, or ChatGPT to run this calculator.
This calculator isn't in MCP yet — but install once for 17 others your AI can call.
Start with
Sprint Velocity Calculator
Review completed story points and their variation to inform sprint planning.
Updated
Ready
AvgVelocity = mean(CompletedPoints[]) over RollingWindow sprints
The rolling window summarizes recent sprints. Use the distribution and upcoming capacity when planning; no historical statistic guarantees delivery.
What is sprint velocity?
Velocity is the story-point total a team completes in a sprint. Average velocity is the sum of completed points divided by the number of sprints. Compare sprints with similar length, availability, estimation scales, and definitions of done.
Reading the results
A team completing 30 points consistently is easier to plan around than one ranging from 20 to 60. Review the spread alongside the average, and account for upcoming leave, dependencies, and work mix.
P85 is an upper historical percentile: about 85% of recorded sprints completed that many points or fewer. It is not a lower commitment met in 85% of sprints. The approximate confidence interval describes uncertainty in the mean, not the range of the next sprint.
Comparing teams
There is no universal story-point target by team size. Teams use different estimation scales, and points per developer do not measure individual productivity. Scrum.org explains the limits of velocity comparisons.
A planning example
A team averaging 45 points might plan 38 if upcoming capacity is lower. This is a planning choice, not a claim of 85% success. Compare the next sprint with the plan and record scope changes before adjusting the baseline.
Interpreting the mean interval
This calculator uses a normal approximation with rounded statistics. Small samples and changing sprint conditions limit its usefulness. NIST describes confidence limits for the mean.
What is Sprint Velocity?
Sprint velocity is the work a team completes per sprint, measured in story points. Averaging recent sprints can help forecast capacity. A useful baseline comes from the team’s own history; a higher number alone does not mean better performance.
Velocity Formula
Average Velocity = Total Story Points Completed ÷ Number of Sprints
Team-specific baseline
Use recent sprint results to forecast capacity, and investigate changes in scope, team, or workflow.
Rate this calculator:
Velocity benchmarks by team size
| Segment | Benchmark |
|---|---|
| Within one team | Compare recent sprints |
| Across teams | No universal point target |
Common questions
What is sprint velocity in agile development?
Sprint velocity is the amount of work completed in a sprint, usually measured in story points. It can help a team plan when its estimation scale and working conditions are reasonably consistent. It does not directly measure delivered customer value or compare productivity across teams.
How do you calculate average sprint velocity?
Add completed points across the selected sprints and divide by the number of sprints. For 25, 30, and 28 points, the average is 27.67. Compare sprints of similar length and note changes in staffing or work before using the average to plan.
What is a good sprint velocity?
There is no universal good velocity. Team size, estimation scales, and work differ. Use your team’s history to understand variation and plan feasible work; a higher point total alone does not mean higher productivity or more customer value.
How can teams improve their sprint velocity?
Work on what slows delivery: technical debt, blockers, context switching, repetitive tasks, and difficulties working together. Break large stories into smaller ones, improve your estimates, and protect the team from mid-sprint changes. Raising point estimates to make velocity look better defeats the purpose of tracking it.
Why does sprint velocity fluctuate?
Check what changed between sprints. Leave, illness, team changes, or a different sprint length can affect velocity. So can harder technical work, dependencies, unfamiliar technology, and unplanned tasks. Look at the trend across several sprints before drawing a conclusion from one.
How do you use velocity for sprint planning?
Use recent completed work as a starting point, then account for planned absences, dependencies, unplanned work, and changes in sprint length. Discuss uncertainty rather than committing to a fixed percentage of the average. Review the plan with the team.