Agile Velocity Predictor
Predict how many sprints are needed to clear your product backlog by dividing total story points by your team's average velocity from the last three sprints. Use it during release planning when stakeholders ask for a delivery forecast.
About this calculator
Agile velocity is the average number of story points a team completes per sprint, calculated from recent historical data. This calculator averages the last three sprints to smooth out one-off anomalies: Average Velocity = (sprint1 + sprint2 + sprint3) / 3. The number of sprints required to complete the backlog is then: Sprints to Completion = Total Backlog / Average Velocity. Using three sprints strikes a balance — fewer sprints may reflect an unrepresentative sample, while more sprints risk including data from when the team had a different composition or process. Multiplying Sprints to Completion by the sprint length (in weeks) gives a calendar forecast. Because velocity varies naturally by 10–20% sprint to sprint, treat the output as a probabilistic range rather than a fixed date, and update the forecast every sprint with fresh data.
How to use
Your last three sprint velocities were 42, 38, and 45 story points. Your total backlog is 300 points and sprint length is 2 weeks. Step 1 — average velocity: (42 + 38 + 45) / 3 = 125 / 3 ≈ 41.67 points/sprint. Step 2 — sprints to completion: 300 / 41.67 ≈ 7.2 sprints (round up to 8). Step 3 — calendar estimate: 8 sprints × 2 weeks = 16 weeks. Communicate this as approximately 16 weeks, with a realistic range of 14–18 weeks given normal velocity variance.
Frequently asked questions
Why should I use only the last three sprints to calculate velocity instead of all historical sprints?
Using only the most recent three sprints ensures the velocity figure reflects the team's current capacity and process rather than historical conditions that may no longer apply — for example, a team that has grown, lost members, adopted new tooling, or refined its definition of done. Older data can drag the average up or down in ways that mislead release planning. Three sprints is generally enough to smooth out single-sprint anomalies (like a holiday week or a particularly difficult feature) without over-indexing on distant history. If your team has recently undergone significant changes, you might reduce to two sprints or even a single representative sprint.
How accurate is velocity-based forecasting for predicting project completion dates?
Velocity forecasting is a leading indicator rather than a precise prediction — it assumes the backlog size, team composition, and per-point effort remain roughly stable, which is rarely perfectly true. Studies of agile project data suggest that velocity-based forecasts are within 20% of actual delivery dates about 70% of the time when made early in a project. Accuracy improves significantly once 30–40% of the backlog is complete and velocity has stabilized. For more rigorous forecasting, Monte Carlo simulation using your full velocity distribution produces probabilistic completion curves that are substantially more accurate than single-point estimates from an average.
What causes agile team velocity to fluctuate between sprints and how do I stabilize it?
Common causes of sprint-to-sprint velocity variance include unplanned work (production bugs, urgent requests), team member absence, underestimated stories, scope changes mid-sprint, and inconsistent application of the definition of done. Stabilization strategies include protecting the sprint from unplanned interruptions (by reserving a bug-fix budget in capacity planning), improving estimation accuracy through regular retrospectives and reference story calibration, and ensuring the definition of done is agreed and applied consistently. Teams that track the ratio of planned to unplanned work each sprint can identify the dominant cause and address it systematically, typically achieving tighter velocity bands within three to five sprints.