Sprint velocity measures the amount of work a team completes during a sprint, typically expressed in story points or other relative units. When used correctly, it is one of the most valuable planning tools available to engineering managers, enabling predictable delivery and realistic capacity planning.
What Is Sprint Velocity?
Sprint velocity is the sum of effort estimates (usually story points) for all product backlog items completed during a sprint. A story is considered complete only when it meets the team's definition of done, which typically includes code review, testing, and deployment. Partially completed items do not count towards velocity.
Velocity is a lagging indicator-it tells you what the team has delivered, not what they are capable of. Its primary purpose is to support sprint planning by providing a data-driven basis for how much work to commit to in upcoming sprints. Over time, a stable velocity allows engineering managers to forecast delivery timelines with reasonable confidence.
It is important to understand that velocity is team-specific and not comparable across teams. Different teams use different estimation scales, have different definitions of done, and work in different contexts. Comparing velocities between teams is meaningless and can create unhealthy competition.
How to Measure Sprint Velocity Accurately
To measure sprint velocity, sum the story points for every backlog item that meets the definition of done at the end of the sprint. Most project management tools such as Jira, Linear, and Shortcut calculate this automatically. Review the number at the end of each sprint during your retrospective.
Track velocity over at least five to eight sprints before using it for forecasting. A single sprint's velocity is unreliable due to natural variation. Use a rolling average of the last three to five sprints to smooth out anomalies caused by holidays, production incidents, or team changes.
- Only count items that fully meet the definition of done
- Use a rolling average of three to five sprints for planning
- Record the velocity alongside any context such as team absences or major incidents
- Ensure the team is using a consistent estimation approach across sprints
- Track velocity trends over time rather than fixating on individual sprint numbers
Velocity Benchmarks and Stability Targets
There is no universal benchmark for velocity because it is denominated in a team's own estimation units. Instead, focus on stability. A healthy team typically shows velocity variation of no more than fifteen to twenty percent from sprint to sprint. If velocity swings wildly, it signals estimation inconsistency, scope changes, or external disruptions.
A useful benchmark is predictability. Track the ratio of completed points to committed points each sprint. High-performing teams consistently deliver ninety percent or more of their committed work. If your team regularly under-delivers or over-delivers by large margins, it suggests the planning process needs attention.
New teams or teams adopting story points for the first time should expect several sprints of instability. Velocity naturally stabilises as the team builds a shared understanding of what a story point represents. Resist the urge to set velocity targets during this calibration period.
Strategies for Improving Velocity Stability
The most effective way to stabilise velocity is to improve estimation practices. Run regular estimation sessions where the whole team participates, using techniques such as planning poker to surface different perspectives. Over time, the team develops a shared mental model of effort that leads to more consistent estimates.
Reduce scope changes mid-sprint. If your team regularly pulls in or removes items during a sprint, velocity becomes unreliable. Protect the sprint commitment by negotiating scope changes through the product owner and deferring non-urgent additions to the next sprint. This discipline improves both velocity stability and team morale.
- Use planning poker or similar techniques to align estimation across the team
- Break large stories into smaller items to reduce estimation uncertainty
- Protect sprint scope and defer additions to subsequent sprints
- Address recurring blockers that cause stories to spill over between sprints
- Review estimation accuracy in retrospectives and recalibrate as needed
Common Pitfalls When Using Sprint Velocity
The most damaging pitfall is treating velocity as a performance metric. When velocity becomes a target, teams inflate estimates to appear productive, rendering the metric useless for planning. Velocity should be used exclusively for forecasting and capacity planning, never for evaluating team or individual performance.
Another common mistake is comparing velocity across teams. Because story points are relative and team-specific, one team's thirty points may represent the same output as another team's fifty points. Cross-team comparisons lead to gaming, resentment, and ultimately worse outcomes for the organisation.
Finally, avoid using velocity to pressure teams into committing to more work. If leadership demands higher velocity, teams will simply inflate their estimates. Instead, focus on removing impediments and improving engineering practices, which will naturally lead to sustainable delivery improvements.
Key Takeaways
- Sprint velocity is a planning tool, not a performance metric-never use it to evaluate teams or individuals
- Use a rolling average of three to five sprints for reliable forecasting
- Aim for velocity variation of no more than fifteen to twenty percent between sprints
- Velocity is team-specific and should never be compared across teams
- Stabilise velocity by improving estimation practices and protecting sprint scope
Frequently Asked Questions
- Should we use story points or hours for velocity?
- Story points are generally preferred because they measure relative effort rather than time, which accounts for complexity and uncertainty. Hours tend to create false precision and can lead to micro-management. However, the most important thing is consistency-pick one approach and use it reliably.
- What should we do when velocity drops significantly?
- First, investigate the context. A velocity drop often has a clear explanation such as team absences, a production incident, or a particularly complex piece of work. If the drop persists over multiple sprints, look for systemic issues like growing technical debt, unclear requirements, or team morale problems.
- How do we handle velocity when team size changes?
- When team members join or leave, expect velocity to be disrupted for several sprints. New members need onboarding time and existing members spend effort mentoring. Reset your rolling average after the team stabilises and avoid drawing conclusions from the transition period.
- Can velocity be used for long-term roadmap planning?
- Yes, but with appropriate caveats. Use your average velocity to create rough delivery forecasts, but communicate these as ranges rather than fixed dates. A common approach is to provide optimistic, likely, and pessimistic scenarios based on your velocity history.
Get Sprint Planning Templates
Our Engineering Manager Templates include sprint planning worksheets and velocity tracking dashboards to help your team plan more predictably.
Learn More