Sprint Velocity Calculator
Typical values: 7 (1 week), 14 (2 weeks), 21 (3 weeks)
Total story points remaining in the product backlog (optional — needed for release forecasting)
Enter Sprint Data to See Results
Add story points for at least one sprint, then click Calculate Velocity to see average velocity, consistency score, trend analysis, and release forecasts.
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.
Frequently Asked Questions
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.