Sprint velocity calculator
Sprint velocity is the number of story points a team completes in a sprint, averaged over recent sprints. Enter the points you finished in each of your last few sprints and this calculator returns the average, the median, a three-sprint rolling average, and — the part most velocity calculators skip — the range your delivery actually falls in.
The single average is the number everyone quotes and the number that gets teams into trouble. If your last six sprints were 14, 26, 19, 31, 17 and 24 points, your average is 21.8 — and you will miss that commitment roughly half the time, because half your sprints came in below it. The forecast range below tells you which number to commit to and which number to treat as a good day.
Points completed per sprint
Optional: forecast a backlog
At your observed range, 120 points takes 5 to 8 sprints — most likely 6. Quote the upper number to anyone outside the team.
Your inputs are in the URL — copy the address bar to share this result.
How it’s calculated
Velocity = total story points completed ÷ number of sprints
- Completed
- Only stories that met the Definition of Done inside the sprint. Partial credit for unfinished work is the single fastest way to make velocity meaningless.
- Number of sprints
- Three sprints is the minimum for a signal, six is better. Anything older than about eight sprints usually describes a team that no longer exists.
- Forecast range
- The 15th and 85th percentile of your observed sprints. Commit to the low number; treat the high one as the stretch, not the plan.
Worked example: A team with six sprints of history
A six-person squad finished 14, 26, 19, 31, 17 and 24 points over their last six sprints. Here is what those numbers actually say.
| Total points completed | 131 points |
|---|---|
| Average velocity | 21.8 points per sprint |
| Median velocity | 21.5 points per sprint |
| Rolling 3-sprint average | 24 points per sprint |
| Observed range | 14 to 31 points |
| Variability | ±26% — high |
| Forecast range (P15–P85) | 16 to 28 points |
The honest read: commit to 16 points, expect around 22, and celebrate 28. A team that commits to its 21.8-point average here is signing up to miss roughly every other sprint — not because they are slow, but because 26% variability means the average describes almost none of their actual sprints.
Reference table
What your variability percentage means for planning. Variability is the standard deviation of your sprint results divided by the average.
| Variability | What it looks like | How to plan with it |
|---|---|---|
| Under 10% | Sprints land within a point or two of each other | Commit to the average. This is a stable team with well-sliced stories. |
| 10–20% | Normal for a healthy team | Commit slightly below the average and keep a stretch item ready. |
| 20–35% | Sprints regularly double each other | Commit to the low end of the forecast range. Look at story slicing before you look at the team. |
| Over 35% | Velocity is close to noise | Stop forecasting from it. Something structural is wrong: unplanned work, oversized stories, or a team whose membership keeps changing. |
How many sprints of history do you need?
Three sprints is the practical minimum and six is where the number gets trustworthy. Below three you are averaging noise. Above eight or so you are averaging a team that has since changed shape — people joined, the product moved, the definition of done tightened. If your team changed materially, reset the window rather than dragging the old sprints along; a shorter honest history beats a longer misleading one.
Is velocity a productivity metric?
No, and using it as one destroys it. Story points are a relative unit each team invents for itself, so a team doing 40 points is not twice as productive as a team doing 20 — the two teams are using different rulers. The moment velocity is compared between teams or reported upward as performance, estimates inflate and the number stops forecasting anything. Velocity is a planning input for the team that produced it, and nothing else.
Velocity or capacity — which should you plan with?
Both, and they answer different questions. Velocity is empirical: it tells you what this team has historically delivered, holidays and interruptions already baked in. Capacity is prospective: it tells you how many person-hours this particular sprint actually has, which matters when someone is on leave or two people just joined. Use velocity as the default commitment and drop to a capacity calculation when the coming sprint is unusual — a holiday week, a new joiner, a planned incident-response rotation.
Why does the rolling three-sprint average differ from the overall average?
Because it is meant to. The rolling average weights the recent past and reacts faster to a real change — a new team member finding their feet, a chunk of technical debt cleared, a shift to smaller stories. When the rolling average sits well above the overall average, the team is genuinely speeding up and the older sprints are dragging your forecast down. When it sits well below, something has recently gone wrong and the overall average is flattering you.
Where this number misleads you
- Counting partially finished stories. If it did not meet the Definition of Done, it is zero points this sprint and full points next sprint. Partial credit smooths the graph and hides the fact that work is not finishing.
- Comparing velocity between teams. Points are a per-team unit. Cross-team comparison guarantees estimate inflation within a quarter.
- Averaging across a team change. Two people leaving is a new team; start a new window rather than blending the old one in.
- Treating a rising velocity as improvement. Velocity rises when estimates inflate just as reliably as when throughput improves. Check cycle time or delivered scope alongside it.
- Forecasting a fixed date from the average alone. Use the low end of the forecast range for anything you have to say out loud to a stakeholder.
Frequently asked questions
How do you calculate sprint velocity?+
Add up the story points your team completed in each recent sprint and divide by the number of sprints. Only count stories that fully met the Definition of Done inside the sprint — partial credit makes the number useless. Three sprints is the minimum for a meaningful average; six gives you enough data to also see the range your delivery falls in.
What is a good sprint velocity?+
There is no good number, because story points are a unit each team invents for itself. A team delivering 40 points is not faster than a team delivering 20 — they are using a different scale. The only meaningful measure of a good velocity is its stability: a team whose sprints land within about 10–15% of each other can plan reliably, whatever the absolute number is.
Should velocity include bugs and unplanned work?+
Be consistent, and pick the option that matches how you plan. If you estimate bugs in points and pull them into the sprint, count them — otherwise your velocity will systematically under-predict how much room the next sprint has. If you leave bugs unestimated, exclude them and instead reserve a fixed percentage of capacity for them. What breaks forecasting is switching between the two approaches.
Why is our velocity so inconsistent?+
The most common cause by far is story size, not team performance. A sprint containing one 13-point story either finishes it or does not, which swings the total dramatically; a sprint of eight 2- and 3-point stories averages out. If your variability is above about 25%, look at slicing stories smaller before you look at anything else. The next most common causes are unplanned interrupt work and a team whose membership keeps changing.
The numbers say what happened. The retro decides what changes.
FocusRetro gives the same team a calm board for honest feedback, blind voting, and action items that survive until next sprint.
Start a retro freeNo credit card required