What Are Sprint Velocity?
The amount of work a Scrum team completes in a single sprint, typically measured in story points. Used for sprint planning and forecasting delivery timelines.
2-minute setup • No credit card required
What it means
Sprint velocity is an Agile metric that tracks a team's throughput over time. At the end of each sprint, you sum the story points (or other estimation units) of all completed stories — a story must be fully done (coded, reviewed, tested, deployed) to count. Velocity is a lagging indicator: it tells you what the team did complete, not what they could have completed. The power of velocity is in its trend: a stable velocity over 3-5 sprints gives you a reliable planning tool. If your team averages 45 story points per sprint, you can estimate that a 90-point epic will take roughly two sprints. Velocity should never be used to compare teams — story point scales are team-specific and not fungible across teams.
Why Sprint Velocity matter
Sprint velocity solves the 'when will it be done?' question that product managers and stakeholders constantly ask. Without velocity data, delivery estimates are guesses. With 5+ sprints of velocity history, you can forecast completion dates with reasonable confidence using a range (pessimistic = lowest velocity, optimistic = highest velocity). For engineering managers, velocity trends reveal team health: a declining velocity might indicate growing technical debt, team burnout, scope creep, or losing a key team member. A stable velocity during a period of changing requirements shows the team is absorbing change well.
How to measure
At sprint end, sum the story points of all fully completed user stories and bugs. Partially completed work gets zero points — it carries over to the next sprint. Track velocity over at least 5 sprints before using it for planning. Calculate the average and the range (min to max). Use the average for planning estimates and the range for confidence intervals. Pull this data from your project management tool (Jira, Linear, Shortcut). Some teams use actual time instead of story points, but story points are more common because they abstract away individual speed differences.
Real-world example
A team's last 6 sprints show velocities of 38, 42, 45, 35, 44, 40 story points (average: 40.7, range: 35-45). A new epic is estimated at 120 story points. The forecast: optimistic = 120/45 = 2.7 sprints, pessimistic = 120/35 = 3.4 sprints, likely = 120/40.7 = 2.9 sprints. The engineering manager tells stakeholders: 'We'll likely deliver this in 3 sprints, with an outside chance of 3.5 sprints if we hit complications.' This is far more credible than a gut-feel estimate.
Related terms
Common questions
Should you use velocity to compare teams?
Never. Story points are calibrated per-team — a '5-point story' for one team might be a '3-point story' for another. Comparing velocities across teams is meaningless and incentivizes point inflation. Velocity is a planning tool for the team that produced it, not a performance metric for comparing teams.
What if our velocity keeps changing?
Some variation is normal (10-20%). Highly variable velocity (swinging 50%+ between sprints) indicates problems: inconsistent estimation, scope changes mid-sprint, unplanned work eating capacity, or dependencies on other teams. Start by tracking what causes the variance — usually it's one or two recurring issues.
Should managers try to increase velocity?
No. Pushing for higher velocity leads to story point inflation — teams estimate stories higher to 'look faster' without doing more work. Instead, focus on removing impediments (slow reviews, flaky tests, unclear requirements) and velocity will naturally improve. The goal is stable, predictable velocity, not an ever-increasing number.
Is velocity still relevant with continuous deployment?
It's less critical. Teams doing continuous deployment and trunk-based development often switch to throughput (number of items completed per week) and cycle time instead of sprint velocity. Velocity is most useful for teams working in defined sprint cycles with sprint planning ceremonies.
Track Sprint Velocity Automatically
Gitmore turns your git activity into automated reports with real metrics — delivered to Slack and email.
Get Started FreeNo credit card • No sales call • Reports in 2 minutes