What Is Velocity in Agile and How to Calculate It?
Velocity in agile is the average amount of work — usually measured in story points — a team completes per sprint, calculated by tracking completed points across several past sprints. It's used primarily to forecast how much work a team can realistically commit to in future sprints, based on genuine historical performance rather than optimistic guessing.
Quick facts
- Velocity is calculated by averaging completed story points across several recent sprints (typically the last 3-6).
- Velocity is a team-specific number and should never be compared directly across different teams.
- This connects to Story Points vs Hours Estimation, since velocity depends on consistent story point estimation.
How to calculate velocity
| Sprint | Story points completed |
|---|---|
| Sprint 10 | 28 |
| Sprint 11 | 32 |
| Sprint 12 | 25 |
| Sprint 13 | 31 |
| Average velocity | 29 |
To calculate velocity: sum the story points completed (not just attempted) in each of the last several sprints, then divide by the number of sprints. Only fully completed items count — partially finished work carried over to the next sprint shouldn't be counted in the sprint it wasn't finished in.
Why velocity matters
Velocity gives a team and its stakeholders a realistic, evidence-based way to forecast future capacity, rather than relying on optimistic estimates that don't account for real-world interruptions, meetings, and unplanned work. Once a team has a stable velocity established over several sprints, it becomes a genuinely useful planning tool — during sprint planning, the team can commit to roughly the same number of story points they've consistently completed before, rather than guessing.
Why velocity should never be compared across teams
Velocity is not a standardized unit of measurement — different teams calibrate their story point scale differently, meaning one team's "5" might represent similar work to another team's "8." Comparing velocity across teams, or worse, using it as a productivity ranking, misunderstands what the number actually represents and can create unhealthy competitive pressure that damages honest estimation. Velocity is only meaningful as a trend within a single team over time, not as a comparison point between teams.
How velocity stabilizes and becomes useful over time
A new team's velocity is often unstable for the first several sprints, since the team hasn't yet calibrated their story point estimates consistently or fully understood their real capacity. After roughly 3-6 sprints, velocity typically stabilizes into a more consistent, genuinely useful average — which is why using velocity for serious planning purposes generally isn't reliable until a team has this track record established.
A worked example
A team completes 24, 30, 27, and 33 story points across four consecutive sprints, giving an average velocity of roughly 28.5, rounded to 28 or 29 for planning purposes. When planning their next sprint, the team uses this figure as a guide, selecting backlog items totaling around 28-29 points rather than an arbitrary or overly ambitious number — this evidence-based approach produces more realistic, achievable sprint commitments than guessing based on how the team feels at the start of the sprint.
Common mistakes with velocity
- Comparing velocity across different teams, misunderstanding that story point scales aren't standardized between teams.
- Using velocity from too few sprints, before it's had a chance to stabilize into a genuinely reliable average.
- Counting partially completed work as if it were finished, inflating velocity and undermining its usefulness for future planning.
- Treating velocity as a productivity target to maximize, rather than a planning tool — pressuring a team to inflate velocity numbers undermines the honest estimation velocity depends on.
FAQ
How many sprints of data are needed before velocity becomes reliable? Most teams find velocity becomes reasonably stable and useful after 3-6 sprints, though this varies depending on how consistent the team and their work are sprint to sprint.
Should velocity increase over time? It often does gradually as a team matures and calibrates their estimation more consistently, but a stable, predictable velocity is generally more valuable for planning purposes than a velocity that's artificially pushed upward.
Can velocity be used to compare individual team members' productivity? No — velocity is a team-level metric, not an individual one, and using it to evaluate individual performance misunderstands its purpose and can damage honest team estimation.
What should a team do if velocity varies significantly sprint to sprint? Investigate the cause — inconsistent story sizing, frequent scope changes mid-sprint, or team capacity fluctuations (vacations, other commitments) are common causes worth addressing to stabilize velocity into a more reliable planning tool.