Track team velocity, forecast releases, and measure Agile consistency
Sprint velocity is the single most important metric for Agile and Scrum teams. It answers the questions every project manager, product owner, and stakeholder asks: How fast is the team moving? When will the project be done? Are we on track? This free Sprint Velocity Calculator gives you instant, reliable answers based on your team's own historical performance data. Velocity, in Agile terms, is the amount of work a team completes in a single sprint — measured in story points, hours, or task counts. It is calculated simply by dividing the total work completed across multiple sprints by the number of sprints. For example, if your team completed 24, 30, and 27 story points over the last three sprints, your average velocity is 27 story points per sprint. This baseline then drives every downstream forecast: how many more sprints are needed to finish the backlog, when will the project be done, and how much work is realistic to commit to in the next sprint. The reliability of any velocity-based forecast depends directly on how much historical data you have. With just one sprint, you have an initial estimate but almost no predictive power. With three sprints, you have a usable baseline. With five or more sprints, you can spot trends, calculate meaningful variance, and produce forecasts that stakeholders can trust. This is why every major Agile methodology recommends collecting at least three to five sprints of data before committing to a release forecast. Our calculator shows you a warning when you have fewer than three data points, so you always know how much confidence to place in the numbers. One of the most important improvements over basic velocity calculators is range-based forecasting instead of a single point estimate. A single average velocity number can be misleading. Teams naturally have good sprints and bad sprints due to holidays, onboarding new members, technical debt, or unexpected complexity. Communicating a range — "we will likely finish between Sprint 8 and Sprint 12" — is far more honest and far more useful than saying "we will finish in Sprint 10." This calculator gives you all three scenarios side by side: an optimistic forecast based on your best historical velocity, an expected forecast based on your average, and a pessimistic forecast based on your worst sprint. Presenting all three to stakeholders sets realistic expectations and protects the team from over-commitment. Beyond raw velocity numbers, this calculator measures velocity consistency — how stable your team's output is from sprint to sprint. Consistency is calculated using standard deviation: a lower standard deviation means predictable, reliable delivery; a higher deviation signals irregular velocity that could mean the team is taking on too much variability in sprint scope, dealing with frequent interruptions, or has not yet stabilized its estimation practices. A Consistency Score of 75% or higher generally indicates a healthy, predictable team. A score below 50% is a signal worth discussing in retrospective. The calculator also detects the velocity trend over time using linear regression. Is your velocity improving sprint over sprint? Is it stable? Or is it declining? A declining trend could indicate growing technical debt, team burnout, or scope creep that needs to be addressed. An improving trend often reflects a maturing team that is getting better at estimation and delivery. For teams that want to go deeper, the optional Capacity Planning mode lets you cross-check your historical velocity against your team's theoretical capacity. Enter your team size, average availability percentage, working hours per day, and your team's story points per hour ratio. The calculator shows total available hours, theoretical sprint capacity, and the recommended safe planning capacity — which applies a 20% buffer to account for unexpected interruptions, bug fixes, and context switching. Comparing theoretical capacity against historical average velocity is one of the most powerful ways to diagnose whether your team is working sustainably or is consistently overcommitted. The Burndown Tracker section helps you monitor the current sprint in real time. Enter the total story points committed for the current sprint, the sprint length in days, how many days have elapsed, and how many points have been completed. The calculator tells you exactly how fast you need to burn down remaining points to finish on time and whether your actual burn rate is ahead of or behind the required pace. As a best practice, remember that velocity is a team-level planning metric — never an individual performance indicator. Using it to compare developers or to pressure teams into higher numbers is a well-documented antipattern that leads to story point inflation and broken trust. Velocity exists to help teams forecast reliably and to help product owners make informed scope and prioritization decisions. Use it as the planning tool it was designed to be.
Understanding Sprint Velocity
What Is Sprint Velocity?
Sprint velocity is the amount of work an Agile development team completes in a single sprint, measured in story points, hours, or task counts. It is calculated by dividing the total completed work units across multiple sprints by the number of sprints. Only fully completed user stories count toward velocity — partially done work is excluded entirely. Velocity is a team-level metric used for planning and forecasting, never for evaluating individual developers. It naturally fluctuates from sprint to sprint due to team changes, holidays, technical complexity, and scope variability, which is why using an average of the last three to five sprints is strongly recommended over any single sprint's output.
How Is Sprint Velocity Calculated?
The core formula is straightforward: Average Velocity = Sum of completed story points / Number of sprints. Beyond the average, teams should track minimum velocity (worst sprint), maximum velocity (best sprint), and standard deviation to understand the natural variance. Release forecasts are derived by dividing remaining backlog points by average velocity for the expected scenario, by maximum velocity for the optimistic scenario, and by minimum velocity for the pessimistic scenario. Date-based forecasts multiply the number of sprints needed by the sprint duration in days, then add that to today's date. Capacity-based estimates multiply team size by availability percentage by sprint duration by hours per day by story points per hour to compute a theoretical maximum sprint capacity.
Why Does Sprint Velocity Matter?
Velocity is the foundation of Agile release planning. Without a reliable velocity baseline, teams cannot commit to delivery dates with any confidence, and product owners cannot make informed decisions about scope and prioritization. With a stable velocity history, teams can give stakeholders a realistic delivery range instead of a guess, help product owners decide what to cut or defer to hit a deadline, size the backlog realistically against available team capacity, and identify sprint-over-sprint trends that signal team health problems before they become crises. Velocity also serves as a leading indicator: a declining velocity trend often precedes missed deadlines by several sprints, giving teams time to intervene.
Limitations of Sprint Velocity
Velocity is a useful planning tool but comes with important caveats. First, it is team-specific — you cannot compare velocity between teams because story point scales are relative to each team's calibration. Second, velocity can be gamed if teams feel pressure to report higher numbers, leading to inflated estimates that destroy forecast accuracy. Third, velocity does not reflect quality — a team can complete 50 story points of buggy code and report high velocity while accumulating technical debt. Fourth, velocity becomes less reliable after significant team composition changes since the team is effectively starting over with new capacity. Finally, early sprints often show high variability as teams calibrate their estimation process, so three to five stable sprints of data are the minimum for meaningful forecasting.
How to Use the Sprint Velocity Calculator
Enter Story Points for Each Sprint
Type the number of story points your team completed in each sprint. Give each sprint a name (Sprint 1, Sprint 2, etc.) and optionally add notes explaining any unusual velocity — holidays, team changes, or major incidents. Only count fully completed user stories; partial stories do not count.
Set Sprint Duration and Remaining Backlog
Enter your sprint duration in days (14 for two-week sprints is most common). Then enter the total story points remaining in your product backlog. This enables the release forecast section, which shows you optimistic, expected, and pessimistic completion dates side by side.
Review Velocity Metrics and Trend
Read your average velocity, min, max, and velocity per day. Check the Consistency Score to understand how predictable your team's output is. Review the trend indicator — Improving, Stable, or Declining — to spot team health signals before they become problems.
Use Capacity Planning and Burndown (Optional)
Open Capacity Planning mode to cross-check your historical velocity against your team's theoretical capacity. Open the Burndown Tracker to monitor the current sprint in real time. Export to CSV to share the data with stakeholders or import it into project management tools.
常见问题
How many sprints do I need before velocity is reliable?
Most Agile practitioners recommend a minimum of three sprints to establish a usable baseline, with five or more sprints providing statistically reliable results. With fewer than three sprints, a single outlier sprint — caused by a holiday, a team member absence, or an unusually complex story — can skew the average significantly. By the time you have five or more sprints, the law of large numbers begins to work in your favor: individual outliers have less impact on the average, and the velocity range naturally narrows. Mountain Goat Software's velocity range calculator requires a minimum of five sprints before it will generate a forecast range. This calculator shows a warning when you have fewer than three sprints to help you calibrate your confidence level appropriately.
Should I use story points, hours, or task counts?
Story points are the most widely used unit in Scrum and Agile teams because they measure relative effort and complexity rather than absolute time. They account for the fact that different team members work at different speeds and that some tasks are inherently uncertain. Hours are useful for teams that prefer time-based planning or are transitioning from waterfall methodologies. Task counts work well for teams with very consistent task sizes where each ticket represents roughly the same amount of work. Whichever unit you choose, be consistent. Mixing story points from one period with hours from another will produce meaningless velocity calculations. The key is that the unit should reflect effort the team has actually completed, not effort estimated or in progress.
Why is my velocity fluctuating so much between sprints?
High sprint-to-sprint velocity variation is extremely common, especially in teams that are new to Agile or are still calibrating their estimation process. Common causes include team size changes (new hires or departures), holidays and planned time off, stories that span sprint boundaries (causing points to appear in a different sprint than the work was done), sudden technical complexity that was not captured in estimation, scope changes mid-sprint, and excessive interruptions from support work or bug fixes. The best diagnostic tool is the notes field — recording why a sprint was high or low helps distinguish natural variation from systemic problems. A Consistency Score below 50% is a useful conversation starter for retrospective discussions about sprint planning and scope stability.
Can I compare velocity between teams?
No. Story points are relative within a team — they reflect that team's specific calibration of effort, complexity, and risk. A story that Team A rates as 5 points might be a 2 for Team B and an 8 for Team C, depending on each team's experience, technology stack, and sizing scale. This means velocity numbers are only meaningful when compared to that same team's historical data. Trying to compare Team A's velocity of 40 against Team B's velocity of 60 and concluding Team B is more productive is a common but serious misuse of the metric. It leads to gaming, inflated estimates, and broken trust. Velocity is a planning tool for the team, not a management measurement tool across teams.
Should partially completed stories count toward velocity?
No — this is one of the most important rules in velocity tracking. A user story that is 80% complete at the end of a sprint contributes zero to velocity. The story should be moved to the next sprint, where it can be completed and counted in full. Allowing partial credit creates several problems: it inflates velocity artificially, it makes forecasting less accurate because you are counting work that has not yet delivered value, and it encourages cutting corners to close out partially done stories by the sprint deadline. The correct approach is to size stories small enough that they can realistically be completed within a single sprint, so partial completion situations are rare. Stories that are too large to complete in one sprint should be split into smaller stories before sprint planning.
What is the 20% buffer in capacity planning and why is it important?
The 20% planning buffer means committing to only 80% of your team's theoretical maximum capacity in each sprint. This buffer accounts for the reality that no sprint ever goes exactly to plan. Teams routinely deal with unplanned work — production incidents, bug fixes, ad hoc requests, code reviews, documentation, and meetings that run long. Without a buffer, these interruptions directly erode the committed sprint scope and lead to consistently incomplete sprints. The 20% figure is an industry rule of thumb; some teams use 15%, others use 25%, depending on how much unplanned work they typically absorb. Consistently failing to complete committed sprint scope is often a sign that the team is not applying a sufficient planning buffer, not that the team is underperforming.