Hong Life CalculatorsUnderstanding the sprint velocity and release forecast calculator — concept and principle
Velocity is the amount of work, usually in story points, that a team finishes in one sprint. This calculator averages your recent sprint velocities and divides the remaining backlog by that average to forecast how many sprints, and how many weeks, are still needed. Product owners and Scrum Masters use it to answer the question "when will this be done?" with a range instead of a promise.
How it is calculated
- Average velocity v̄ = (v₁ + v₂ + … + vₙ) ÷ n, using the velocities you enter.
- Sprints needed = ⌈backlog ÷ v̄⌉, rounded up because a partial sprint still has to be run.
- Weeks = sprints needed × sprint length in weeks.
- Optimistic / pessimistic sprints = ⌈backlog ÷ highest velocity⌉ and ⌈backlog ÷ lowest velocity⌉.
Velocities and backlog must use the same unit (points, ideal days or item counts).
The principle
The forecast assumes the team will keep delivering at roughly the rate it has shown recently, so past throughput is used as a measured rate, like distance ÷ speed = time. Averaging several sprints smooths out holidays, sick days and uneven story sizes. Using the best and worst observed sprints gives a simple range: if every remaining sprint went as well as your best one, or as badly as your worst one. The true finish date usually lies between the two.
Worked example
- Velocities: 21, 25, 19, 23. Sum = 88, so v̄ = 88 ÷ 4 = 22 points.
- Backlog 180 ÷ 22 = 8.18, rounded up to 9 sprints.
- 9 sprints × 2 weeks = 18 weeks.
- Optimistic: 180 ÷ 25 = 7.2 → 8 sprints. Pessimistic: 180 ÷ 19 = 9.47 → 10 sprints. Result: 8 / 10.
How to read the result
Communicate the range (here 8–10 sprints, 16–20 weeks) rather than the single middle value. A wide gap between optimistic and pessimistic means your velocity is unstable, and the forecast deserves less confidence. Velocity is only comparable within one team, because each team calibrates its own point scale. Re-run the forecast every sprint: the backlog usually grows as new work is discovered, which pushes the date out.
Common mistakes
- Comparing velocity between teams or using it as a performance target, which encourages point inflation.
- Forgetting that the backlog changes; a fixed 180 points rarely stays fixed.
- Using only one or two sprints, or including sprints from before a team change.
- Counting partially finished stories as delivered points.
Frequently asked questions
How many past sprints should I average?
Three to six recent sprints is a common choice. Fewer is noisy; many more may include periods when the team or the work was different.
Should I use story points or item counts?
Either works if the backlog uses the same unit. Counting finished items (throughput) is often just as accurate when items are sliced to similar sizes.
What if a new team has no velocity yet?
Run one to three sprints first, or make a cautious estimate and replace it with real data as soon as it exists.
Sources: Mike Cohn, Agile Estimating and Planning, Prentice Hall, 2005 · Ken Schwaber and Jeff Sutherland, The Scrum Guide (scrumguides.org)