Most engineering teams track sprint velocity as a number on a burndown chart and never ask what's actually driving it. Sprint velocity measures how much work a squad completes in a sprint, expressed in story points, issue count, or another agreed unit. When your velocity is inconsistent or declining, it signals a process problem worth diagnosing: scope creep, unclear acceptance criteria, unplanned work, or blocked players. This page covers the definition, how to measure and benchmark sprint velocity, a real-world example, and how to surface the data without manual spreadsheet work.
TL;DR: Sprint velocity = total story points (or units) completed in a sprint. Use it to forecast capacity and spot delivery process issues, not to rank your players.
Key takeaways
- Sprint velocity is the total amount of work a squad completes in a single sprint, measured in story points or equivalent units. It gives engineering leaders a repeatable signal for forecasting and for identifying when delivery processes are breaking down before a deadline slips.
- Sprint velocity is calculated by summing the story points of all completed issues at the end of each sprint. A healthy squad typically stabilizes within a 10–15% variance band after three to five sprints. Wide swings from sprint to sprint are the signal worth investigating, not the average number itself.
- The most common mistake teams make with sprint velocity is treating it as a performance score. Comparing velocity across squads or using it to rank players ignores differences in story point calibration, squad size, and work type. Velocity is a planning tool, not a productivity grade.
- DevStats surfaces sprint velocity data automatically by connecting to your issue tracker, with trend views across sprints and benchmarks against 1,000+ engineering teams. Start a free trial to see your squad's numbers in under two minutes.
Sprint velocity definition
Sprint velocity is the total number of story points (or equivalent work units) a squad completes in a single sprint. It is calculated at the end of each sprint by summing the points of all issues moved to "done" before the sprint closes.
The formula is straightforward: Sprint velocity = sum of story points completed in a sprint. Over time, averaging three to five sprints gives you a rolling velocity that is far more useful for capacity planning than any single sprint result. Teams that connect velocity trends to their planning accuracy data get a clearer picture of whether estimates are improving or systematically off.
Stable sprint velocity directly supports stakeholder commitments. When your squad's velocity is predictable, product managers can make reliable roadmap promises and engineering leaders can allocate capacity with confidence.
Why sprint velocity matters for engineering teams
Squads that do not track sprint velocity consistently end up in a reactive planning loop. Without a reliable historical baseline, sprint planning becomes guesswork, and missed commitments accumulate until a major deadline slips. Invisible scope creep and unplanned interruptions erode capacity without anyone noticing until the damage is done.
Sprint velocity connects directly to the engineering leader's core KPIs: on-time delivery, predictable roadmap execution, and sustainable team pace. When velocity drops unexpectedly, it is often the first signal of a deeper issue, such as a rising volume of unplanned work, a bottleneck in code review, or a squad carrying too much context-switching overhead. Tracking velocity trends alongside throughput gives you both the planning signal and the delivery signal in one view.
Within the SPACE framework, sprint velocity sits at the intersection of Efficiency and Activity. It measures process output, not individual effort. Measurement gives you the starting point. The engineering manager decides what to do with it.
How to measure sprint velocity
To calculate sprint velocity, pull the sum of story points for all issues marked complete by sprint close from your issue tracker (Jira, Linear, GitHub Issues, or equivalent). Exclude issues that were pulled mid-sprint without being completed, as counting partial work inflates the number and erodes planning reliability.
The primary data source is your issue tracker. No Git data is required for velocity itself, though pairing it with issue cycle time helps explain why velocity is high or low in a given sprint. Use a rolling three-sprint average as your planning baseline. DevStats's benchmarks feature lets you compare your squad's velocity trends against similar teams by size and industry.
No universally published benchmark exists for sprint velocity the way DORA publishes deployment frequency benchmarks, because story point scales vary widely across teams. The table below describes qualitative performance levels based on internal consistency and planning accuracy, which are the signals that matter most.
| Performance level | Sprint velocity benchmark | What it signals |
|---|---|---|
| Elite | Variance within 10% across 5+ sprints | Stable estimation, predictable delivery, minimal unplanned work |
| High | Variance within 15–20% across 5+ sprints | Generally predictable with occasional disruption; planning is reliable |
| Medium | Variance of 20–35% sprint to sprint | Estimation inconsistency or recurring unplanned interruptions worth investigating |
| Low | Variance above 35% or consistent decline over 3+ sprints | Systemic planning breakdown, significant unplanned work, or squad capacity issues |
Note: benchmarks vary by squad size, sprint length, and story point calibration. Use these ranges as directional signals, not absolute targets.
Sprint velocity in practice: a real example
A VP of Engineering at a 40-person SaaS company noticed that her platform squad's velocity had dropped 30% over six consecutive sprints. The raw number looked like a performance problem. When she pulled the sprint data alongside the squad's unplanned work ratio, she found that roughly 35% of each sprint was being consumed by support escalations that were never accounted for in planning. The velocity drop was a capacity signal, not an output problem.
She restructured the sprint planning process to reserve a fixed buffer for support work and introduced a weekly triage rotation to contain interruptions. Three sprints later, planned velocity stabilized and the squad's planning accuracy improved significantly. The data surfaced the pattern. She made the call on how to address it.
How to improve sprint velocity
1. Audit your unplanned work ratio each sprint. Before adjusting story point estimates or sprint scope, measure what percentage of each sprint is consumed by work that was not in the original plan. If unplanned work consistently exceeds 20%, the planning problem is external to the estimation process. Address the source of interruptions first.
2. Run a story point calibration session every quarter. Estimation drift is one of the most common causes of velocity swings. Bring the squad together to re-reference your point scale against two or three anchor stories. Consistent calibration makes velocity a reliable planning input rather than a noisy signal.
3. Reduce carry-over issues. Issues that spill across sprint boundaries inflate the next sprint's apparent velocity and distort your rolling average. Review carry-over rate sprint over sprint. If more than two issues carry over consistently, the squad is overcommitting. Tighten scope before the sprint starts, not after it ends.
4. Pair velocity with PR cycle time. A squad can complete all planned issues on paper while PRs sit in review for days, pushing actual delivery out. Monitoring PR cycle time alongside velocity tells you whether completed work is actually shipping. DevStats surfaces both signals in one view so you can see where the delivery chain is slowing down.
5. Review squad allocation before each sprint. Planned capacity changes when players take leave, shift to on-call, or get pulled into cross-squad work. Checking allocation data before sprint planning prevents the squad from committing to velocity targets that do not reflect actual available capacity.
Sprint velocity vs. throughput
Sprint velocity and throughput are related but measure different things. Velocity counts story points completed per sprint; throughput counts the number of issues or pull requests completed per unit of time, regardless of size.
| Sprint velocity | Throughput | |
|---|---|---|
| Measures | Story points completed per sprint | Count of work items completed per time period |
| Starts when | Sprint begins | Work item enters active state |
| Ends when | Sprint closes | Work item reaches done |
| Best for | Sprint capacity planning and forecast | Flow efficiency and continuous delivery measurement |
Use velocity for sprint-based planning and forecasting. Use throughput when you want to measure delivery flow independent of estimation units, especially useful for squads moving toward continuous delivery models.