Sprint Velocity: What It Is, How to Measure It, and Why It Matters

Sprint velocity is one of the most watched numbers in Scrum — and one of the most abused. Teams treat it like a performance score, managers compare it across teams, and the pressure to grow it every sprint turns an honest planning tool into a game that everyone loses.

Velocity is a planning compass. Its only job is to tell a team how much work they can reliably commit to in the next sprint, based on what they actually finished in the last few. Used for that purpose, it makes planning more realistic and gradually replaces optimistic guessing with calibrated confidence. Used as a management lever, it produces all the behaviors — point inflation, cherry-picking, sandbagging — that make it useless for the thing it was designed to do.

This guide explains what velocity actually is, how to measure it correctly, what causes it to fluctuate, and — critically — what you should never use it for.

What Is Sprint Velocity?

Sprint velocity is the total story points completed by a team in a single sprint. "Completed" has a precise meaning here: an item counts only if it fully satisfies your team's Definition of Done at the end of the sprint. Partially done work — 90% finished, code-complete but not tested, done but waiting for design sign-off — contributes exactly zero to velocity.

That binary rule is not arbitrary. Velocity exists to create a predictable planning baseline. The moment you start crediting partial work, the number becomes disconnected from shipped output, and forecasting breaks down.

A few properties worth being explicit about:

• Velocity is measured per sprint. One number per sprint, period.
• It is team-specific. Story point scales are relative and defined independently by each team. A "5" on Team A means nothing on Team B.
• Average velocity is your planning input. Rolling average over the last 3–5 sprints, not a single sprint or a theoretical maximum.
• Story points are not hours. They encode complexity, uncertainty, and effort together. Converting them to hours destroys their value.
• Velocity measures completed value, not activity. A sprint where the team worked hard but finished nothing has a velocity of zero.

Story points and velocity: the relationship

Story points are relative estimates — they express how complex a piece of work is compared to a reference story the team agrees on. The most common scale is Fibonacci (1, 2, 3, 5, 8, 13, 21) because the gaps between values force honest acknowledgment that larger items are inherently harder to estimate precisely.

Velocity emerges naturally from consistent story point usage over time. A team that estimates honestly and tracks what they finish ends up with a velocity that reflects their actual throughput. The number doesn't need to be managed — it just needs to be measured honestly.

How to Calculate Sprint Velocity

The mechanics are simple. At the end of the sprint, look at your board. For every item in the Done column that fully satisfies your Definition of Done, record its story point value. Sum them. That's your sprint velocity.

The planning velocity is a rolling average of recent sprints. Most teams use 3–5 sprints. Too few and you're over-indexing on recent flukes; too many and you're including old data from when the team or codebase was different.

In this example, the team's planning velocity heading into Sprint 7 is approximately 40 points (using a 3-sprint rolling average of Sprints 4–6). That's the number they should plan against — not 44 (their best sprint), not 34 (their worst), not 50 (what the product owner would like).

What "Good" Velocity Actually Looks Like

The most common mistake teams make is trying to define a target velocity or compare their number to other teams. Neither is meaningful. Story point scales are team-defined and non-transferable. A team averaging 80 points per sprint is not twice as productive as a team averaging 40 — they just calibrate their scale differently.

Within a single team, here is what healthy velocity looks like:

• Consistent: sprint-to-sprint variability of ±15–20% is normal. Variability of ±50% or more points to systemic problems — unstable team composition, chronic interrupt work, or unreliable estimation.
• Predictable: the team can commit to within 10–15% of average velocity and reliably deliver. Predictability is the goal, not growth.
• Stable for mature teams: a team that has been together for 6+ months and knows its codebase should have a relatively flat velocity. Genuine productivity gains show up as delivering higher-value work at the same velocity, not as a larger number.
• Growing modestly for new teams: newly formed teams will see velocity grow during the first 3–6 months as they calibrate their estimate scale and learn the codebase. This growth is real, but it levels off.

"A team with a stable velocity of 35 that consistently delivers everything they commit to is more valuable than a team with a 'growing' velocity of 60 that ships 60% of what they plan every sprint."

Why Velocity Fluctuates Between Sprints

Every experienced Scrum Master has fielded the question: "Why did our velocity drop last sprint?" The honest answer is almost always one of eight causes — most of which are expected and healthy, not alarming:

1. Team composition changes

PTO, sick leave, parental leave, new joiners, or engineers moving between teams all change the available capacity. A sprint where one of five developers is absent for three days is 12% below full capacity — and velocity should be proportionally lower. This is not a problem; it's expected. Factor it in during sprint planning.

2. Estimation drift

As teams learn more about a product domain, their intuitive sense of complexity changes. A story that was "5 points of uncertainty" early on might be "3 points of well-understood work" six months later. Recalibration is healthy but produces apparent velocity changes that have nothing to do with actual productivity. Periodic re-estimation of reference stories helps keep the scale anchored.

3. Carry-over from the previous sprint

Items that were almost done at the end of Sprint N and get finished at the start of Sprint N+1 count toward Sprint N+1's velocity, not Sprint N's. This creates a systematic low-velocity sprint followed by a high-velocity sprint for the same actual output. It's an accounting artifact, not a productivity signal.

4. Unplanned interrupt work

Production incidents, urgent customer escalations, and security patches consume capacity without appearing in the sprint plan. If your team regularly experiences interrupt work that isn't allocated for in planning, velocity will be consistently lower than planned — and the right fix is to explicitly reserve a "buffer" in each sprint for known interrupt categories, not to plan higher to compensate.

5. Technical debt and infrastructure work

Refactoring, dependency upgrades, and CI/CD improvements are typically underestimated in story points because teams instinctively calibrate complexity against feature work. Infrastructure work is often genuinely harder than its point value suggests, which depresses velocity relative to plans. The solution is better calibration, not avoidance.

6. New team members ramping up

A new engineer joining an existing team reduces velocity for 4–8 weeks during onboarding — not just their own contribution, but through the time senior engineers spend on pairing, code review, and context-sharing. This is an investment with a real payoff, but it should be planned for explicitly.

7. External dependencies blocking completion

Stories blocked by another team's API, a design review that didn't happen, or a stakeholder sign-off that was delayed don't count toward velocity even if the code is written. Blocked items are some of the most corrosive velocity signals because the team did the work but gets no credit. Surface blockers early and split work to avoid partial completion being the common case.

8. Definition of Done evolving

When a team raises the bar on their Definition of Done — adding automated tests, requiring accessibility checks, mandating documentation — the same features now take more work to complete. Velocity will temporarily drop, then stabilize at a new baseline that reflects higher-quality output. This is healthy, but the velocity drop will look alarming to anyone measuring velocity without understanding the DoD change.

How to Use Velocity for Sprint Planning

The right use of velocity is narrow and specific: deciding how many story points to commit to in the upcoming sprint. Everything else is a misuse.

The basic planning formula

Start with your rolling average velocity (last 3–5 sprints). Adjust for known capacity changes. That's your sprint commitment target.

Example: Your team of 5 engineers averages 48 points at full capacity (10 working days each = 50 team-days). Next sprint, one engineer is on PTO for 4 days. Available capacity = 46 team-days. Adjusted target = (46 / 50) × 48 = 44 points.

Pull stories from the top of the prioritized backlog until you reach that target. Stop there. Do not fill up to the maximum because the sprint feels "light" — the point of velocity-based planning is to commit to what you can reliably deliver, not to maximize utilization.

Forecasting future releases

Velocity also enables release forecasting: if a feature set has been estimated at 200 story points and your team's average velocity is 40 points, you can forecast approximately 5 sprints (10 weeks for 2-week sprints) to complete it. Add a confidence interval based on velocity variability — if your velocity ranges from 34 to 48, your range is 4–6 sprints.

This kind of probabilistic forecasting is far more honest than "we'll be done in 10 weeks" — it communicates the range of likely outcomes rather than false precision.

Good sprint planning goes hand-in-hand with well-written, consistently sized user stories. If your story points are inconsistent because stories themselves aren't well-scoped, velocity loses its forecasting value. See our guide on how to write user stories with consistent sizing for the foundation that makes velocity reliable.

Velocity Anti-Patterns to Avoid

The following patterns are common, tempting, and corrosive. Each one makes velocity progressively less useful as a planning tool.

The sprint retrospective is the right place to surface velocity anti-patterns before they become cultural norms. See our sprint retrospective templates for structured formats that surface these dynamics without blame.

Velocity vs. Throughput vs. Cycle Time

Velocity is one of three common engineering productivity metrics — and it's worth being precise about what each one measures, because they answer different questions.

These metrics complement rather than replace each other. Velocity tells you what to plan; throughput tells you how many items flow through; cycle time tells you where items are getting stuck. Engineering teams that track all three have a much richer picture of how work is actually moving than teams that fixate on velocity alone.

For teams wanting a deeper data-driven view of engineering performance, DORA metrics add a fourth lens — deployment frequency, lead time, change failure rate, and MTTR — that velocity and throughput don't capture at all.

And for understanding how velocity fits into the full Scrum operating model — including how to structure the planning sessions that use velocity as an input — see our deep dive on Agile vs. Scrum for the conceptual foundation.