Agile Sprint Velocity Calculator
Sprint velocity: definition, formula, and how to use it
Sprint velocity is a Scrum planning metric that describes how much work a team typically finishes in one sprint. It is usually measured in story points per sprint. Velocity is most useful for team-level forecasting (what the team can likely deliver next), not for evaluating individual performance.
What this calculator returns
Enter the total completed story points across a set of recent sprints and the number of sprints included. The calculator outputs:
- Average velocity (story points per sprint)
- A short copy-ready summary you can paste into sprint planning notes
Velocity formula (MathML)
The standard average velocity calculation is:
- V = average velocity (points per sprint)
- P = total completed story points across the selected sprints
- S = number of sprints included
How to choose the right inputs
Velocity is only meaningful when you measure it consistently. For best results:
- Count only “Done” work (per your Definition of Done). Exclude partial stories and in-progress work.
- Use comparable sprints (same sprint length, similar ceremonies). Avoid mixing 1-week and 2-week sprints in the same average.
- Use a stable window: many teams average 3–6 recent sprints. Fewer than 3 can be noisy; more than 6 may hide recent change.
- Exclude atypical sprints only if you have a clear policy (e.g., sprint 0 setup, major outage response). Document the rule so the metric remains trustworthy.
Step-by-step: using the calculator
- Sum the story points completed across your chosen recent sprints.
- Enter that sum in Total story points completed.
- Enter how many sprints you included in Number of sprints.
- Click Calculate Velocity to get average points per sprint.
- Optionally click Copy Result to share the summary.
Worked example (with forecasting)
Suppose your team completed the following story points in the last five 2-week sprints: 32, 28, 35, 30, and 25. The total is:
Total completed points = 32 + 28 + 35 + 30 + 25 = 150
Number of sprints = 5
Your average velocity is:
V = 150 ÷ 5 = 30 points per sprint
Forecasting backlog completion: if your remaining backlog is estimated at 240 points, a basic forecast in sprints is:
Sprints needed ≈ Remaining points ÷ Velocity = 240 ÷ 30 = 8 sprints
That’s a rough planning estimate. In practice you’ll want a range (best/likely/worst) using a recent minimum and maximum, or a percentile approach, especially if your velocities vary.
How to interpret the result
- Use it for capacity planning: start sprint planning near your average velocity, then adjust for time off, on-call load, spikes, or expected interruptions.
- Watch the trend, not just the number: a stable velocity suggests predictable delivery; a declining velocity suggests increased load, scope creep, quality issues, or team changes.
- Don’t compare across teams: story points are relative and team-specific. Two teams’ “5 points” rarely mean the same thing.
Velocity vs other delivery metrics (comparison table)
Velocity is not the only way to forecast. The table below helps you pick the right tool for the question you’re answering.
| Metric | Unit | Best for | Common pitfalls |
|---|---|---|---|
| Velocity | Story points / sprint | Sprint planning, short-term forecasting for one team | Gaming points, cross-team comparison, using it for performance |
| Throughput | Items (tickets) / time period | Flow-based teams, forecasting when item sizes are similar | Misleading if item sizes vary widely |
| Cycle time / lead time | Days (or hours) | Predicting when individual items will finish | Needs consistent workflow states and clean data |
| Capacity (hours) | Hours / sprint | Availability planning (time off, part-time, on-call) | Doesn’t translate directly into value delivered |
Assumptions and limitations (read before using)
This calculator intentionally uses a simple average. That makes it easy to use, but it comes with important assumptions:
- Stable team and process: velocity is most predictive when team membership, tooling, and ways of working are broadly stable.
- Comparable sprint length: do not mix different sprint durations in the same average (e.g., 1-week and 2-week sprints).
- Consistent story point scale: if your team recently recalibrated pointing, historical velocities may not be comparable.
- Definition of Done is consistent: if “Done” changes (more QA, more documentation), velocity may change even if productivity didn’t.
- Outliers distort averages: a single unusual sprint (release crunch, incident response, holidays) can skew the result. Consider using 3–6 sprints and documenting exclusions.
- Not a delivery guarantee: velocity is a planning signal, not a promise. Use ranges and revisit each sprint.
- Not an individual metric: using velocity to evaluate people tends to encourage unhealthy behavior (inflating points, avoiding hard work) and reduces trust.
FAQ
How many sprints should I average?
A common starting point is 3 to 6 recent sprints. If your work varies a lot, use more data and consider forecasting with a range rather than a single number.
What if the team changed recently?
If you had significant changes (new hires, people leaving, major scope shift, new tech stack), treat older sprints as less relevant. Recalculate using only sprints after the change, and expect higher uncertainty for a few iterations.
Should I include bugs, chores, and spikes?
Include any work that your team estimates in points and completes under the same Definition of Done. If some categories are unpointed, keep them consistent; otherwise velocity won’t represent the full load.
Can velocity predict an exact release date?
Velocity can help estimate how many sprints a backlog might take, but it cannot produce an exact date without additional assumptions (sprint cadence, team stability, scope change rate). For date forecasting, combine velocity with uncertainty ranges and ongoing scope management.
How This Velocity Calculator Works
The calculator uses a simple average based on your historical data. You provide:
- Total story points completed across several past sprints (only work that is fully done).
- Number of sprints included in that total.
It then computes your team’s average velocity as story points per sprint. This is the key planning unit in Scrum-based forecasting.
For example, if your team completed 180 points over the last 5 sprints, the calculator divides 180 by 5 and reports a velocity of 36 points per sprint.
Velocity Formula
The standard formula for average sprint velocity is:
Velocity = Total completed story points ÷ Number of sprints
Using mathematical notation:
Where:
- V is the average velocity (story points per sprint).
- P is the total number of completed story points across the selected sprints.
- S is the number of sprints included in that total.
In plain language, you add up all the completed story points for the sprints you are considering, then divide by how many sprints there were. The result is the average points your team finishes in one sprint.
Interpreting the Result
The calculator returns a single number, for example 34. You should read this as:
- 34 story points per sprint on average.
Here are some practical ways to use that number:
- Sprint planning: Use your average velocity as a starting point for how many points to pull into the next sprint. If your velocity is 34, you might tentatively plan 30–34 points, then adjust for holidays, absences, or especially risky work.
- Release forecasting: If your product backlog or a specific release scope has, say, 200 points remaining, divide 200 by your velocity to estimate how many sprints you will need.
- Trend analysis: Track velocity over time to see whether it is relatively stable. Big swings often indicate process issues, estimation changes, or major context changes (e.g., new team members).
Velocity is best used as a range rather than a single exact figure. Many teams look at a band such as “we usually deliver between 30 and 36 points per sprint” and plan conservatively within that band.
Worked Example
Suppose your Scrum team has just finished its fifth sprint. Over those five sprints, you completed the following story points:
- Sprint 1: 28 points
- Sprint 2: 32 points
- Sprint 3: 30 points
- Sprint 4: 35 points
- Sprint 5: 25 points
First, add them together:
28 + 32 + 30 + 35 + 25 = 150 points total.
Next, count the number of sprints: there are 5.
Apply the formula:
V = 150 ÷ 5 = 30 points per sprint
In the calculator, you would enter:
- Total story points completed: 150
- Number of sprints: 5
The reported velocity is 30. You could then use this to answer questions such as:
- “How many points can we plan next sprint?” — Start around 30 points, then adjust based on known time off or risky work.
- “Roughly how many sprints until we finish a 210-point backlog?” — 210 ÷ 30 = 7 sprints. If sprints are two weeks long, that is about 14 weeks, assuming scope does not grow.
Using Velocity to Forecast Backlog Completion
Once you know your velocity, you can make simple, high-level forecasts. A common use case is estimating how many sprints remain for a given backlog or release scope.
Use this rule of thumb:
Number of sprints ≈ Remaining story points ÷ Velocity
For example, if you have 260 story points remaining and your average velocity is 32 points per sprint:
260 ÷ 32 ≈ 8.1 → approximately 8–9 sprints.
Remember that this is an approximation. Backlogs evolve, requirements change, and teams improve their collaboration practices. Regularly recalculate velocity using the latest finished sprints and adjust your forecast accordingly.
Comparison: Velocity vs. Other Planning Approaches
Velocity is one of several ways teams plan and forecast. The table below compares it with a few related concepts.
| Approach | Main unit | Primary use | Typical strengths | Typical limitations |
|---|---|---|---|---|
| Velocity (this calculator) | Story points per sprint | Sprint planning and high-level forecasting | Grounded in real delivery history; simple to calculate and explain. | Sensitive to changes in estimation scale and team composition. |
| Throughput | Items completed per time period | Kanban-style planning and flow analysis | Does not require story points; works well with small, similar-sized items. | Less precise if item sizes vary widely; needs stable workflow policies. |
| Hours-based estimation | Person-hours or person-days | Task-level scheduling and capacity checks | Intuitive for new teams; aligns with time-based thinking. | Can give a false sense of precision; often drifts from reality. |
| No-estimates / flow-based | Cycle time and lead time | Continuous delivery planning | Focuses on actual flow; can reduce estimation overhead. | Requires disciplined workflow tracking and stable process. |
This calculator assumes you already use story points in Scrum or a similar framework. If your team does not estimate in points, alternative approaches like throughput or cycle time may be more appropriate.
Assumptions and Limitations
Velocity is powerful but easy to misuse. Keep these assumptions and caveats in mind when using the result from this calculator:
- Consistent sprint length: The formula assumes that all sprints are roughly the same duration (for example, every sprint is two weeks). Mixing one-week and three-week sprints in the same calculation can distort the average.
- Stable story point scale: Velocity only makes sense if your team keeps the same definition of a story point over time. If you recently changed your estimation approach or reference stories, calculate velocity using only sprints with the new scale.
- Completed work only: Count only stories that meet your team’s Definition of Done. In-progress items should not be included in the total points until they are truly complete.
- Representative sample of sprints: Use several recent, “normal” sprints. Extremely unusual sprints (e.g., major outages, large training events) may need to be treated as outliers and excluded.
- Not a performance score: Velocity is a planning tool, not a way to compare teams or judge individual developers. Different teams use different story point scales, so comparing “Team A delivers 50 points” vs. “Team B delivers 30 points” is misleading.
- Forecasts are approximate: The backlog size, team composition, technology stack, and domain complexity can all change. Treat any forecast based on this calculator as a best-effort estimate, not a fixed commitment.
- Does not capture quality or outcomes: A high velocity does not automatically mean high value. Bugs, rework, and low-impact features may all contribute to points but not to meaningful outcomes.
Used thoughtfully and in context, velocity can support more realistic conversations with stakeholders. Used as a rigid target or performance metric, it can drive unhealthy behaviors such as inflating estimates or cutting quality to “hit the number.”
Good Practices for Using Velocity
To get the most out of the calculator and your velocity metric, consider these practical tips:
- Recalculate regularly: Update your inputs every few sprints so that your velocity reflects the current team and context.
- Use ranges, not absolutes: Look at minimum, maximum, and median velocities over the last few sprints to plan within a sensible band.
- Discuss context in retrospectives: When velocity jumps up or down, explore why. Did estimation change? Was there unusual time off? Did you tackle especially simple or complex work?
- Combine with qualitative insight: Pair the numeric output with the team’s judgment. The people doing the work can best assess whether a forecast feels realistic.
When you treat velocity as an input to collaborative planning rather than a target to hit, it becomes a useful, low-friction tool for aligning expectations and guiding delivery.