Agile Sprint Velocity Calculator
Introduction: what sprint velocity means and why teams calculate it
Sprint velocity is a simple planning measure used by Scrum and agile teams to describe how much work they usually finish in one sprint. Most teams express that work in story points, so the result is usually read as story points per sprint. This calculator helps you turn a small set of historical sprint data into one practical average that can support sprint planning, release conversations, and backlog forecasting.
The idea is straightforward. If your team completed a certain number of points over several finished sprints, you can divide the total by the number of sprints to estimate your average pace. That average does not tell you how hard people worked, and it should not be used to compare one team with another. Instead, it gives your team a shared planning reference based on actual completed work.
Used well, velocity helps answer questions such as: “How many points should we tentatively bring into the next sprint?” or “If the backlog still contains 240 points, roughly how many sprints might remain?” Used poorly, velocity becomes a target or a performance score, which usually leads to distorted estimates and less trustworthy planning. The goal of this page is to keep the metric practical, understandable, and grounded in healthy agile use.
What this calculator returns
Enter the total completed story points from a group of recent sprints and the number of sprints included in that total. The calculator returns your average sprint velocity and also prepares a short summary sentence that you can copy into planning notes, status updates, or backlog review documents.
This is intentionally a simple average. It does not try to model uncertainty, confidence intervals, or changing team composition. That simplicity is useful because it makes the result easy to explain. At the same time, it means you should interpret the output as a planning aid rather than a promise.
Velocity formula
The standard average sprint velocity calculation is:
In this formula, V is average velocity, P is the total number of completed story points across the sprints you selected, and S is the number of completed sprints in that sample. In plain language, you add up the points from finished work and divide by how many sprints produced that work.
Because the result is an average, it smooths out some normal sprint-to-sprint variation. A team may finish 25 points one sprint, 34 the next, and 30 after that. The average gives a more stable planning baseline than any single sprint on its own.
How to choose the right inputs
The quality of the result depends on the quality of the inputs. Velocity is only meaningful when the underlying data is consistent. The most important rule is to count only work that is truly finished according to your team’s Definition of Done. Partial stories, almost-done work, and items that slipped into the next sprint should not be included in the completed total.
It also helps to use a set of sprints that are reasonably comparable. If your team normally works in two-week sprints, mixing those with one-week or three-week sprints will make the average harder to interpret. Likewise, if your team recently changed its estimation scale, added several new members, or shifted to a very different type of work, older sprints may no longer represent current capacity very well.
Many teams start with the last 3 to 6 completed sprints. That range is often long enough to reduce noise but short enough to stay relevant. If your environment changes quickly, use a shorter and more recent window. If your work is highly variable, you may want to review both the average and the spread between low and high sprints.
How to use the calculator
Using the calculator is simple. First, total the story points your team completed across the recent sprints you want to analyze. Second, count how many sprints are included in that total. Third, enter both values into the form and calculate the result. The output will show the average number of story points completed per sprint.
For example, if your team completed 150 points over 5 finished sprints, the calculator divides 150 by 5 and returns 30.0 story points per sprint. That means your recent average pace has been about 30 points each sprint. You can then use that figure as a starting point for planning, while still adjusting for holidays, support load, onboarding, technical risk, or other known constraints.
Worked example
Suppose your team completed the following story points in five recent two-week sprints: 32, 28, 35, 30, and 25. The first step is to add them together. That gives a total of 150 completed points. The second step is to count the number of sprints, which is 5.
Now apply the formula:
The result is 30 story points per sprint. If the remaining backlog is estimated at 240 points, a rough sprint forecast would be 240 divided by 30, which suggests about 8 sprints. That does not mean the work will definitely finish in exactly 8 sprints. It means that, if the team continues working at a similar pace and the scope stays reasonably stable, 8 sprints is a useful planning estimate.
How to interpret the result
The result should be read as an average, not as a commitment. If the calculator returns 34.0, that means your team has recently completed about 34 story points per sprint on average. It does not mean every future sprint will land exactly on 34. Some sprints will be lower because of vacations, incidents, or difficult technical work. Others may be higher because of cleaner stories, fewer interruptions, or a more focused sprint goal.
In sprint planning, many teams use velocity as a starting point rather than a hard cap. If your average is 34, you might tentatively plan around 30 to 34 points and then adjust based on context. If several people are out, if a release is unusually risky, or if a large spike is expected, planning below the average may be wiser. If the sprint is unusually clean and the team has full availability, planning near the average may be reasonable.
Velocity is also useful for trend awareness. A stable pattern suggests the team’s system is fairly predictable. A sudden drop may point to process friction, quality issues, changing priorities, or team changes. A sudden jump may reflect easier work, changed estimation habits, or a one-off sprint rather than a permanent improvement. Looking at the story behind the number is always more valuable than reacting to the number alone.
Velocity compared with other delivery metrics
Velocity is helpful, but it is not the only planning metric available. Teams that estimate in story points often find velocity useful because it aligns with sprint-based planning. Teams that work in a more continuous flow may prefer throughput or cycle time instead. The right metric depends on how your team organizes work and what question you are trying to answer.
| Metric | Unit | Best for | Common pitfalls |
|---|---|---|---|
| Velocity | Story points / sprint | Sprint planning and short-term forecasting for one team | Cross-team comparison, gaming estimates, treating it as a target |
| Throughput | Items completed / time period | Flow-based teams and forecasting when work items are similarly sized | Can mislead when item sizes vary a lot |
| Cycle time / lead time | Days or hours | Predicting when individual items may finish | Requires clean workflow data and consistent states |
| Capacity | Hours / sprint | Availability planning and staffing discussions | Does not directly measure delivered value |
If your team already estimates in story points and plans in sprints, velocity is often the most natural metric for near-term planning. If your team does not estimate in points, forcing velocity into the process may create more confusion than clarity.
Assumptions and limitations
This calculator uses a simple average, so it assumes a fairly stable context. The result is most useful when the team, sprint length, estimation scale, and Definition of Done are reasonably consistent. If those conditions change, historical velocity becomes less predictive.
It is also important to remember that velocity does not measure quality, customer value, or business impact. A team can complete many points while still producing low-value work or creating rework. In the same way, a lower-velocity sprint may still be successful if it reduced risk, solved a major production issue, or delivered a strategically important capability.
Outliers matter too. A sprint dominated by incident response, a holiday period, or a major release crunch can distort the average. Some teams exclude clearly atypical sprints, but if you do that, use a consistent rule and document it. Otherwise the metric becomes easy to manipulate and less trustworthy.
Most importantly, velocity should never be used as an individual performance score. Story points are relative, team-specific estimates. Comparing one team’s velocity with another team’s velocity is usually misleading, and using velocity to judge people often encourages inflated estimates or unhealthy delivery behavior.
Good practices for using velocity well
Velocity works best when it supports conversation rather than replacing it. Recalculate it regularly using recent completed sprints. Pair the number with team judgment. If the team says the next sprint contains unusual uncertainty, that context matters more than blindly following the average.
It is also wise to think in ranges. If your last several sprints were 28, 30, 31, 34, and 35, the average is useful, but the range is useful too. Planning with a realistic band often leads to better stakeholder conversations than pretending one exact number can predict the future.
Finally, use velocity to improve planning quality, not to chase a bigger number. Healthy teams focus on finishing valuable work reliably, maintaining quality, and learning from each sprint. When velocity is treated as a byproduct of a stable system rather than a score to maximize, it becomes much more useful.
Frequently asked questions
How many sprints should I average?
A common starting point is 3 to 6 recent sprints. Fewer than 3 can make the result noisy, while too many can hide recent changes in team capacity, process, or scope.
What if the team changed recently?
If several people joined or left, if responsibilities shifted, or if the team moved to a new technology area, older sprints may no longer reflect current reality. In that case, calculate velocity using only the more recent and comparable sprints.
Should bugs, chores, and spikes be included?
Include them if your team estimates them in story points and counts them as completed under the same Definition of Done. The key is consistency. If some work types are pointed and others are not, velocity may not reflect the team’s full load.
Can velocity predict an exact release date?
No. Velocity can support a rough forecast of how many sprints a backlog may require, but exact dates depend on sprint cadence, scope changes, team stability, dependencies, and uncertainty. It is better used for directional planning than for exact promises.