Agile how to calculate velocity
Estimate your team’s velocity using completed story points, sprint count, and capacity adjustments. This calculator helps Scrum teams understand average throughput, forecast future sprint output, and compare baseline versus adjusted velocity in one premium dashboard.
- Best for: Scrum Masters, Product Owners, Agile Coaches, engineering managers, and PMO teams.
- Formula used: Velocity = Total completed story points across selected sprints ÷ Number of sprints.
- Forecasting tip: For planning, many teams use a confidence range around average velocity rather than a single number.
Your results will appear here
Enter completed story points for multiple sprints, then click Calculate velocity.
How to calculate agile velocity accurately
Agile velocity is one of the most practical planning signals available to Scrum teams, but it is also one of the most misunderstood. In simple terms, velocity tells you how many story points a team actually completes in a sprint. When used correctly, it helps teams forecast work, set sprint expectations, and discuss delivery with more realism. When used poorly, it can become a vanity metric that encourages point inflation rather than better outcomes.
If you are searching for “agile how to calculate velocity,” the core idea is straightforward: add up the story points for all items completed within a sprint and accepted as done, then compare those totals across several sprints to find an average. The more stable your team, backlog refinement, and estimation model are, the more useful that average becomes. The key phrase here is accepted as done. If a user story is only partially finished or has not met the agreed Definition of Done, it should not count toward velocity for that sprint.
The calculator above simplifies the process by letting you enter completed points from several sprints and then generating average velocity, points per week, and a capacity-adjusted forecast. That gives you a quick way to answer practical questions such as: “How much can we plan for next sprint?” or “What should our target be if one teammate is away?”
What agile velocity really measures
Velocity is not a universal productivity score. It is a team-specific measure of throughput based on that team’s own estimation scale. A velocity of 30 story points for Team A does not mean Team A is “better” than Team B with a velocity of 20. Story points are relative, not absolute. Different teams size work differently, have different definitions of complexity, and work within different technical contexts.
Velocity is most useful when you apply it inside a single stable team over time. It can help answer questions like:
- How many story points can we realistically pull into the next sprint?
- Is our throughput stable, improving, or highly variable?
- What release forecast can we build from our recent delivery pattern?
- How should we adjust planning when team capacity changes?
It should not be used to compare teams, rank developers, or pressure teams into increasing points. Once teams start gaming estimates, velocity loses planning value.
The standard formula for velocity
The standard formula is:
For example, if a team completed 24, 30, 28, and 32 story points over four sprints, the average velocity is:
(24 + 30 + 28 + 32) ÷ 4 = 28.5 story points per sprint
That number becomes your baseline for future planning. If your next sprint has lower capacity, you can reduce that baseline. If you have extra available team time and expect similar work composition, you may increase it modestly, though conservative planning is usually better.
What should count in the calculation
- Only completed and accepted user stories or backlog items.
- Only items that meet the team’s Definition of Done.
- Only points assigned before work started, not re-estimated after completion just to make the numbers look better.
- Only work finished within the sprint boundary.
What should not count
- Partially completed stories.
- Carried-over work not accepted in the sprint.
- Defects or unplanned work that were never estimated in points, unless your team has a consistent process for estimating them.
- Hours, tasks, or number of tickets as a substitute for story points.
Step-by-step method for calculating velocity
- Estimate backlog items consistently. Use relative sizing such as 1, 2, 3, 5, 8, or 13 story points. Teams often use Planning Poker or affinity estimation.
- Track what was truly completed. At sprint review or sprint close, total only the points for accepted items.
- Record velocity every sprint. Capture the completed points in a simple log or tool.
- Use a rolling average. Most teams use the last 3 to 6 sprints to smooth random variation.
- Adjust for known capacity changes. Planned leave, new team members, holidays, training, or production support can all shift likely output.
- Forecast using a range. A range is safer than a single-point promise, especially when work varies in complexity.
Worked example: calculating average and adjusted velocity
Imagine a Scrum team completed the following points over five sprints:
- Sprint 1: 24 points
- Sprint 2: 30 points
- Sprint 3: 28 points
- Sprint 4: 32 points
- Sprint 5: 27 points
Total completed points = 141. Number of sprints = 5. Average velocity = 141 ÷ 5 = 28.2 points per sprint.
If the next sprint includes a holiday week and your expected team capacity is 10% lower, a practical adjusted forecast becomes:
Adjusted velocity = 28.2 × 0.90 = 25.38
Most teams would round to a planning target of about 25 points, perhaps with a confidence range from 24 to 28 depending on historical stability. This is exactly where calculators are useful. They reduce manual math and create consistent planning assumptions sprint after sprint.
Comparison table: velocity over time and planning interpretation
| Sprint | Completed Story Points | Interpretation | Planning Insight |
|---|---|---|---|
| 1 | 24 | Lower baseline sprint | May reflect startup friction, unplanned work, or refinement gaps |
| 2 | 30 | Strong delivery sprint | Possible indicator of improved clarity or fewer blockers |
| 3 | 28 | Near the mean | Useful as a realistic planning anchor |
| 4 | 32 | High end of range | Should not become a mandatory target if conditions were unusually favorable |
| 5 | 27 | Stable output | Supports an average around 28 points per sprint |
Why a velocity range is better than a single number
Experienced Agile practitioners usually forecast with ranges, not precise promises. Software work is uncertain. Dependencies, unplanned defects, production incidents, stakeholder changes, and technical surprises can all affect throughput. A single average is useful, but it is even more valuable when paired with a lower and upper planning band.
A team with strong estimation discipline and stable work types may use a narrow range such as 85% to 115% of average velocity. A newer team, or one handling mixed feature and support work, may need a broader range. Historical minimum and maximum values can also provide a practical forecast band.
For example, if average velocity is 28.2 points:
- 85% to 115% planning band = about 24 to 32 points
- Historical min and max from recent sprints = 24 to 32 points
Notice how similar those ranges are in this example. That alignment can build confidence in your next sprint forecast.
Common mistakes teams make when calculating velocity
1. Counting partially completed stories
This is the most common error. Velocity depends on completed outcomes, not progress. If a story is 90% complete but not accepted, it should not count. Otherwise, your planning data becomes inflated and less reliable.
2. Changing point values after the sprint
Some teams retroactively increase points on stories that turned out to be harder than expected. That makes the historical record look cleaner, but it weakens estimation learning. Keep estimates stable and improve future sizing instead.
3. Comparing one team’s velocity to another
Because story points are relative, cross-team comparison is misleading. Team A’s “5” may be Team B’s “3” or “8.” Velocity is for local planning, not leaderboard management.
4. Treating velocity as a performance KPI
Once leaders tie rewards or pressure to higher velocity, teams often respond by splitting stories differently or inflating estimates. This creates the illusion of improvement without actual delivery gains.
5. Ignoring capacity changes
A stable historical average is useful only if the upcoming sprint has similar conditions. If one or two people are on leave or the sprint includes holidays, your forecast should be adjusted downward.
Statistics and evidence from industry sources
Reliable agile planning should be grounded in empirical feedback and adaptation. Several respected institutions publish evidence that supports iterative planning, transparency, and data-informed process improvement:
| Source | Statistic or Evidence | Why It Matters for Velocity |
|---|---|---|
| U.S. Government Accountability Office | GAO’s Agile assessment guidance emphasizes iterative delivery, customer feedback, and measuring progress frequently across short cycles. | Velocity fits this empirical model by using completed increments from each sprint as a planning input. |
| Carnegie Mellon University Software Engineering Institute | SEI research on estimation and software measurement highlights the need for historical data and organizational consistency when forecasting software work. | Velocity works best when teams maintain stable estimation patterns and inspect historical trends. |
| National Institute of Standards and Technology | NIST software engineering resources stress repeatable processes, quality controls, and clear definitions for accepted work products. | Velocity depends on a strict Definition of Done and consistent acceptance criteria. |
Those sources do not prescribe one exact velocity formula for every team, but they reinforce the same principle: software delivery becomes more predictable when teams use short feedback loops, clear definitions, and historical evidence.
How to use velocity in release planning
Velocity becomes especially useful when you shift from sprint planning to release forecasting. Suppose your backlog for a release contains 140 points of work and your recent average velocity is 28 points per sprint. A rough forecast is:
140 ÷ 28 = 5 sprints
If your sprint length is two weeks, that suggests about 10 weeks of delivery, not counting major risks, scope changes, or external dependencies. If your adjusted forecast is only 25 points due to reduced capacity, the release estimate becomes:
140 ÷ 25 = 5.6 sprints
That means you may need 6 sprints instead of 5, or you may need to reduce scope. This is where velocity supports better portfolio and stakeholder conversations. It makes tradeoffs visible.
How many sprints should you use for the average?
There is no universal number, but many teams use the most recent 3 to 6 sprints. Too few sprints can create noise. Too many can hide current realities if the team, technology, or work type has changed. A practical guideline is:
- 3 sprints: good for a rapidly changing environment, but more volatile
- 5 sprints: strong balance for many mature teams
- 6 or more sprints: useful when you want more smoothing and the team is very stable
If your team composition changes significantly, it is often wise to reset your baseline and rebuild velocity history rather than over-relying on old data.
Authority references for deeper reading
For readers who want credible institutional guidance on iterative delivery, estimation discipline, and software process measurement, start with these sources:
- U.S. Government Accountability Office Agile Assessment Guide
- Carnegie Mellon University Software Engineering Institute
- National Institute of Standards and Technology
Best practices for trustworthy velocity
- Keep team membership reasonably stable when using velocity for planning.
- Estimate at the story level, not the task level.
- Refine backlog items before sprint planning so stories are clear and comparable.
- Use a Definition of Done that is explicit, shared, and auditable.
- Review outlier sprints in retrospectives and note why they were unusually high or low.
- Forecast with a range and communicate uncertainty early.
- Never use velocity alone to judge team health. Pair it with quality, customer outcomes, lead time, and predictability.
Final takeaway
When people ask “agile how to calculate velocity,” the answer is simple in formula but nuanced in practice. Add the completed story points from each sprint, divide by the number of sprints, and use that average as a planning baseline. Then improve the usefulness of the metric by counting only finished work, maintaining estimation consistency, adjusting for capacity changes, and planning with a forecast range rather than a single target.
The calculator on this page gives you a fast way to apply those principles. Enter your historical sprint completions, review your average and adjusted velocity, and use the chart to see how your recent throughput behaves. Used responsibly, velocity is not a score to chase. It is a tool to help teams plan realistically, learn from actual delivery, and make better commitments over time.