Sprint velocity measures how much work a team completes in a sprint, typically expressed in story points. It is one of the most widely used — and most widely misused — engineering metrics.
Used correctly, velocity is a planning tool. It helps teams forecast how much work they can take on in the next sprint and how long a project will take. Used incorrectly, it becomes a performance metric that incentivizes gaming (inflating story point estimates) and destroys the psychological safety that Agile depends on.
The distinction matters: velocity is a team capacity measure, not a productivity score. It tells you how much a specific team typically completes, so you can plan accordingly. It does not tell you whether that team is "good" or "bad" — comparing velocity across teams is meaningless because different teams estimate differently.
The Formula
Sprint Velocity = Total Story Points Completed in Sprint
Story Points Completed — The sum of story points for all user stories (or tasks) that meet the team's definition of done by the end of the sprint. Only count fully completed work — partial completion does not count.
Average Velocity — The more useful planning figure:
Average Velocity = Sum of Points Completed Over Last N Sprints / N
Use the last 3–5 sprints for a stable average. Shorter windows are noisy; longer windows may not reflect current team capacity (member changes, new technology).
Worked Example
A six-person engineering team with two-week sprints:
| Sprint | Points Committed | Points Completed | Velocity | |---|---|---|---| | Sprint 21 | 34 | 30 | 30 | | Sprint 22 | 32 | 34 | 34 | | Sprint 23 | 36 | 28 | 28 | | Sprint 24 | 32 | 32 | 32 | | Sprint 25 | 34 | 31 | 31 |
Average Velocity: (30 + 34 + 28 + 32 + 31) / 5 = 31 points/sprint
For project planning: If the remaining backlog is estimated at 186 story points:
Estimated Sprints = 186 / 31 = 6 sprints (12 weeks)
Add a buffer of 20–30% for uncertainties: realistic estimate is 7–8 sprints (14–16 weeks).
Velocity Stability Index:
Coefficient of Variation = Standard Deviation / Mean = 2.1 / 31 = 6.8%
A CV below 10% indicates stable, predictable velocity. Above 20% suggests planning problems, inconsistent estimation, or frequent disruptions.
What "Good" Velocity Looks Like
Velocity is not benchmarkable across teams. What matters is:
Stability: Consistent velocity sprint over sprint (low coefficient of variation). This indicates reliable estimation and predictable delivery.
Trending: Velocity should be roughly stable or gently increasing as the team matures. Sharp increases suggest point inflation. Sharp decreases suggest problems (team disruption, technical debt, unclear requirements).
Commitment accuracy: The ratio of completed to committed points. Consistently completing 90–100% of committed work indicates good planning. Consistently over-committing (completing 60–70%) indicates the team is not using velocity data for planning.
| Pattern | What It Signals | |---|---| | Stable (±10%) | Healthy team with consistent planning | | Gradually increasing | Team improving or learning a new codebase | | Volatile (±30%+) | Planning problems, estimation inconsistency, external disruptions | | Steadily declining | Technical debt, team morale issues, scope creep | | Suddenly jumping up | Point inflation (gaming), not real productivity improvement |
Common Misuses
1. Comparing Velocity Across Teams
Team A completes 40 points/sprint. Team B completes 25 points. Team A is not necessarily more productive — they may just estimate higher. Story points are a team-specific abstraction. Cross-team comparison is meaningless and counterproductive.
2. Using Velocity as a Performance Metric
The moment you reward teams for increasing velocity, they will inflate estimates. A task that was 3 points becomes 5 points, and "velocity improves" without any real productivity change. Velocity should inform planning, not evaluation.
3. Pushing Teams to Increase Velocity
Demanding higher velocity without addressing systemic issues (technical debt, unclear requirements, operational interruptions) leads to burnout, quality reduction, and estimation gaming. Address the constraints; velocity improvement follows.
4. Counting Partial Work
If a story is 80% complete at sprint end, it should not count toward velocity. Only completed stories count. Counting partial work inflates velocity and hides the problem of stories that consistently spill over.
How to Use Velocity Effectively
1. For Sprint Planning
Use average velocity (last 3–5 sprints) as the starting point for how much work to commit to. If average velocity is 31 points, commit to 28–32 points. Do not habitually over-commit.
2. For Release Planning
Estimate remaining work in story points. Divide by average velocity to get estimated sprints. Add 20–30% buffer for unknowns. This gives stakeholders a data-informed timeline.
3. For Identifying Disruptions
When velocity drops significantly from the average, investigate. Common causes: team member absence, unexpected production issues, unclear requirements that caused rework, and technical debt that made development harder than expected.
4. For Capacity Impact Analysis
If a team member leaves or joins, velocity will change. Historical data helps estimate the impact: if a 6-person team averages 31 points and one person leaves, expect velocity to drop by roughly 15–20% (not exactly 1/6, because of collaboration effects).
Related Metrics
- Cycle Time — Time from work started to work completed. More granular than velocity and measures flow efficiency.
- Lead Time — Time from request to delivery. Includes waiting time before work starts.
- Throughput — Number of items completed per sprint (count, not points). Simpler and harder to game than velocity.
- Sprint Burndown — Shows daily progress within a sprint. Reveals whether the team is on track mid-sprint.
- Defect Rate — High velocity with high defect rate means the team is shipping fast but not shipping well.
Velocity is a useful tool when understood as a team planning metric, not a performance measure. Use it for what it is designed for — capacity planning and release forecasting — and resist the temptation to turn it into something it is not.