Velocity in Agile: How to Measure Team Throughput
Agile velocity is one of the most practical numbers a Scrum team can track. It tells you, on average, how much work your team actually finishes in a sprint, which is the foundation of any honest release forecast or capacity plan.
Most teams hear about velocity early in their agile journey, misuse it as a performance score, and then wonder why it creates pressure instead of clarity. This guide explains what velocity is, how to calculate it correctly, and how to use it as a forecasting tool without gaming the number.
What Is Velocity in Agile?
Agile velocity is the average number of story points a team completes in a sprint. It's calculated by dividing the total points finished across several recent sprints by the number of those sprints.
That's the whole definition. Velocity doesn't measure quality, speed, efficiency, or effort. It measures completed throughput over a fixed time window, nothing more.
The key word is "completed." Story points that were started but not finished before the sprint ended do not count toward velocity. Partial credit doesn't exist here. This strictness is what makes velocity a reliable forecasting input: if a team has an average velocity of 42 points, you can project future sprints with reasonable confidence because the number reflects what actually shipped, not what was attempted.
Key Facts
- Teams that track velocity for at least 6 sprints produce release date estimates that are 40% more accurate than teams that estimate purely by gut feel (Scrum Alliance State of Scrum, 2023).
- The average Scrum team velocity ranges from 20 to 60 story points per sprint, though the number itself is less important than its stability over time (VersionOne State of Agile, 2023).
- Roughly 60% of agile teams report using velocity as their primary capacity-planning metric, making it the most widely adopted throughput measure in Scrum (Digital.ai State of Agile Report, 2023).
How to Calculate Velocity
The formula is straightforward.
Velocity = Total completed story points / Number of sprints measured
Use the last 3 to 5 sprints for a rolling average. Fewer than 3 sprints gives a noisy picture; more than 7 starts blending in data from periods when the team had a different composition or different estimation habits.
Here's a worked example for a team running 2-week sprints:
| Sprint | Points Committed | Points Completed |
|---|---|---|
| Sprint 1 | 48 | 42 |
| Sprint 2 | 45 | 44 |
| Sprint 3 | 50 | 39 |
| Sprint 4 | 46 | 45 |
Rolling average velocity (4 sprints): (42 + 44 + 39 + 45) / 4 = 42.5 points
The team's working velocity is roughly 42 points per sprint. Notice that the committed number doesn't matter for the calculation. What matters is what crossed the "done" line before the sprint ended. If Sprint 3 looks low, investigate the cause (scope change? mid-sprint blocker? holiday?) rather than dismissing it or inflating it.
How to Use Velocity for Forecasting
Once you have a stable velocity, you can answer the question every stakeholder eventually asks: "When will this be done?"
The approach is simple. Sum the story points on your remaining backlog (or the backlog slice for a given release), then divide by your average velocity.
Sprints to completion = Remaining backlog points / Average velocity
Say your team has 210 points left in a release backlog and a velocity of 42. That's 5 sprints, or 10 weeks on a 2-week cadence. That's your forecast.
A few practices make this more useful in practice:
- Use a range, not a point estimate. Plug your lowest recent sprint result and your highest to get a confidence band. "Between 4.5 and 6 sprints" is more honest than "exactly 5."
- Reforecast every sprint. As the team completes work, add new items, or removes scope, the projection shifts. Treat it as a live number, not a contract.
- Connect velocity to your backlog refinement habit. Velocity forecasts are only as good as the sprint planning that keeps the backlog sized and ordered. If estimates drift or the backlog goes stale, velocity loses its forecasting power.
- Tie it to roadmap milestones. If your roadmap says a feature ships in Q3, work backward from the deadline to see how many sprints you have, multiply by velocity, and check whether the remaining scope fits. If it doesn't, you have a scope or timeline conversation to have early, not at the deadline.
This forecasting method also pairs well with planning poker, which helps keep story point estimates calibrated across the team so velocity stays meaningful over time.
What Velocity Is NOT
This is where most teams go wrong.
Velocity is not a productivity metric. A team with a velocity of 60 is not "better" than a team with a velocity of 30. Story points are relative to each team's own scale. One team might size a feature at 8 points; another might size the same feature at 3. There's no shared unit. Comparing velocities across teams is meaningless.
Velocity is not a target to increase. When managers set "improve velocity by 20%" as a goal, teams do exactly one predictable thing: they inflate their story point estimates. The number goes up, but the actual output doesn't change. You've just degraded the calibration of your estimation system.
Velocity is not a measure of individual performance. Velocity belongs to the team, not to any one person. Using it to evaluate individuals creates the wrong incentives and breaks the collaborative estimation that makes the metric accurate.
Velocity is not a commitment. Stakeholders sometimes treat velocity as a floor: "You did 44 points last sprint, so you're committed to at least 44 this sprint." That's not how it works. Velocity is a historical average used for planning, not a minimum throughput obligation.
Factors That Affect Velocity
Velocity changes over time, and most of those changes have obvious causes. Knowing what drives variation helps you interpret the numbers rather than react to them.
Team composition changes. When a new person joins, velocity typically drops for 2 to 3 sprints while they ramp up. When someone leaves, the effect is immediate. Neither change means the team is failing.
Holidays and time off. A sprint that straddles a public holiday or has multiple people on vacation will produce lower velocity. Some teams adjust their sprint capacity accordingly; others simply note it when reviewing the average.
Scope changes mid-sprint. Pulling in unplanned work or swapping out stories partway through a sprint breaks the relationship between what was planned and what was completed. This is one reason WIP limits matter: capping work in progress protects the sprint from mid-course interference.
Estimation drift. Over months, teams sometimes unconsciously change how they size work. A "5-point story" in month one might feel like a "3-point story" by month six as the team gets faster at similar work. If velocity trends up steadily without any change in team size or tooling, check whether estimates have drifted rather than assuming the team is genuinely faster.
Technical debt and environmental friction. Slow CI pipelines, frequent production incidents, and code quality issues consume sprint capacity without showing up in the backlog. Teams carrying significant technical debt often have lower and more variable velocity than their capacity would suggest.
Velocity vs Other Flow Metrics
Velocity is a sprint-level metric. It tells you about throughput across fixed time boxes. But it doesn't tell you everything about how work flows through your system.
| Metric | What It Measures | Best For |
|---|---|---|
| Velocity | Completed story points per sprint | Release forecasting, sprint capacity |
| Cumulative flow diagram | Work item counts across workflow stages over time | Spotting bottlenecks, WIP growth, flow stability |
| WIP limits | Maximum concurrent items in a stage | Throughput optimization, reducing context switching |
| Cycle time | Time from start to completion per item | Predictability at the item level |
| Burndown chart | Remaining work within a sprint or release | Real-time sprint health |
Velocity and cumulative flow diagrams are complementary. Velocity gives you the sprint-level forecast number; the CFD shows you whether your workflow is healthy enough to sustain it. A team with good velocity but an unstable CFD (growing WIP bands, frequent band crossings) is heading toward a velocity drop.
How to Improve (Stabilize) Velocity
The goal isn't to maximize velocity. It's to make velocity predictable, so your forecasts are trustworthy. Here's how to get there.
Run consistent sprints. Variable sprint lengths (switching between 1-week and 2-week) make velocity data incomparable. Pick one cadence and stick with it for at least 6 sprints before drawing conclusions.
Complete the definition of done before closing stories. If your team's definition of done is fuzzy, stories drift across the done line at different quality levels, making points incomparable. Sharpen the definition and enforce it.
Protect the sprint from unplanned work. Every mid-sprint fire that pulls a developer away is a direct hit to velocity. Build a lightweight triage process (a product owner filter, a "break glass" rule) that routes urgent items without breaking sprint commitments.
Keep estimations calibrated. Run a brief re-calibration exercise every quarter. Pull 5 to 10 completed stories and re-estimate them with the current team. If new estimates differ significantly from original ones, your velocity data from before the shift needs a mental adjustment.
Track the causes of outlier sprints. When velocity spikes or drops more than 20% from the rolling average, note the cause in your sprint retrospective. Patterns become visible: if holiday sprints consistently drop 25%, you can factor that into capacity planning.
Use backlog refinement consistently. Unrefined backlog items produce unreliable estimates, which produce noisy velocity. Teams that refine regularly maintain more stable velocity because they're working from well-understood, right-sized stories.
Reduce scope churn. Frequent scope changes mid-sprint are the single biggest driver of velocity instability for most teams. Stable sprints with minimal scope change produce stable velocity.
Frequently Asked Questions
How many sprints of data do I need before velocity is reliable? Most practitioners recommend at least 5 to 6 completed sprints before treating velocity as a forecasting input. Before that, you're looking at too small a sample to filter out noise. During the first few sprints, treat velocity as directional, not predictive.
What if our velocity changes dramatically from sprint to sprint? High variance usually signals one of a few things: inconsistent sprint length, frequent mid-sprint scope changes, a recently changed team, or estimation drift. Start by logging the cause of each outlier sprint in your retrospective. Once you can explain the variation, you can address the root cause rather than just averaging around the noise.
Should we share velocity with stakeholders? Share the release forecast, not the raw number. Stakeholders who see the velocity figure in isolation often treat it as a target or a benchmark against other teams. The forecast ("this release is on track for Q3 based on current pace") gives them what they need without creating the wrong pressure.
Can we use velocity without story points? Yes. Some teams track velocity in story count rather than points, which works if their stories are consistently similar in size. Others use t-shirt sizes converted to a numeric scale. The key is that whatever unit you use stays consistent long enough to build a meaningful average.
How is velocity different from capacity? Capacity is planned availability (total team hours in a sprint). Velocity is actual throughput (completed points). Capacity is input; velocity is output. Teams sometimes use capacity to set a sprint goal, but they use velocity to forecast future releases. Conflating the two leads to over-commitment: a sprint at 100% capacity doesn't guarantee 100% of the planned points will complete.
Velocity is a simple number, but teams get the most from it when they stop chasing it and start reading it. A stable velocity means your estimation and delivery habits are consistent enough to plan around. When velocity shifts, that's information: something in the team's environment or process changed, and it's worth understanding what.
Pair it with sprint planning discipline, clean story point estimates, and flow visibility from your cumulative flow diagram, and you have a forecasting system that stakeholders can actually trust.
