Sprint Velocity Calculator

What is sprint velocity?

Sprint velocity is the amount of work a Scrum team completes in a sprint, usually measured in story points. It is a planning tool, not a performance score: its job is to help the team decide how much to pull into the next sprint and to help product owners forecast when a release will be ready. Because each team sizes work differently, velocity only makes sense when you compare a team with its own history.

How to calculate velocity

Add up the story points of every item that met the Definition of Done during the sprint. Items that were started but not finished contribute nothing to that sprint, even if they were 90% done; they count in the sprint where they are completed. Then average across several sprints:

A worked example

A team completed 21, 18, 24, 20 and 23 points over its last five sprints. The total is 106 points, so the average velocity is 106 ÷ 5 = 21.2 points. The rolling average of the last three sprints is (24 + 20 + 23) ÷ 3 = 22.3 points, suggesting the team has settled at a slightly higher pace.

With 120 points left in the release backlog, the team needs 120 ÷ 21.2 ≈ 5.7, which rounds up to 6 sprints at the average pace. At its best sprint (24 points) it would need 5 sprints; at its slowest (18 points), 7. Presenting that 5-to-7 range is far more honest than promising a single date, and it is exactly what the calculator above shows.

Using velocity to forecast

Forecasts built on velocity assume the backlog is estimated consistently and that the team, sprint length and way of working stay roughly the same. When any of those change, recalculate. Two practical habits help:

• Forecast in ranges. Use the slowest and fastest recent sprints, or the average plus and minus one standard deviation, to give a best and worst case.
• Re-forecast every sprint. Each completed sprint adds a data point and reveals scope that has been added to the backlog.
• Adjust for capacity. A sprint with two people on leave will not hit the usual number; our sprint capacity calculator scales velocity to the hours actually available.

Common velocity mistakes

• Treating velocity as a target. When teams are pushed to raise velocity, estimates inflate and the number stops meaning anything.
• Comparing teams. Story points are relative to one team's calibration, so cross-team comparisons are misleading.
• Counting partial work. Giving credit for unfinished stories hides carry-over and makes forecasts optimistic.
• Ignoring unplanned work. Production support and urgent bugs eat into capacity; track them so the velocity reflects reality.

What a healthy velocity chart looks like

A healthy team's velocity moves within a fairly narrow band from sprint to sprint, with dips that have obvious explanations such as holidays or a production incident. Large swings usually point to inconsistent estimation, stories that are too big to finish inside a sprint, or work entering the sprint after planning. A steady downward trend is worth raising in a retrospective: it often signals growing technical debt, unplanned support work or a team member who has been pulled onto other projects. Look for the pattern over five or six sprints rather than reacting to any single number.

Velocity and Kanban

Kanban teams that do not work in sprints usually measure throughput (items finished per week) and cycle time instead of velocity. The forecasting idea is the same: use recent history to predict how long the remaining work will take, expressed as a range.

Velocity without the spreadsheet

In Taskmei, velocity and completion rate are captured automatically every time a sprint is closed, and unfinished items roll back to the backlog so the numbers stay honest. Plan with our sprint planning template if you work in spreadsheets, or let Taskmei keep the history for you.