Every Scrum team ends up asking the same question at the start of a sprint: how much can we take on this time? Velocity is the usual answer, and also one of the most misused numbers in agile.
Velocity is the bridge between estimation and planning: it turns the story points from your estimation sessions into the figure the team uses in sprint planning. This guide shows how to calculate it on a worked example, how to forecast a release with it, and which habits quietly ruin it.
What is sprint velocity?
Sprint velocity is the amount of work a Scrum team completes in one sprint, usually measured in story points. To calculate it, add up the estimates of every backlog item that meets the Definition of Done at the end of the sprint; unfinished items count for zero, with no partial credit. A single sprint says little, so teams average the last three to five sprints, often as a rolling average that drops the oldest sprint each time. Velocity is a planning tool: it helps the team decide how much work to pull into the next sprint, and it helps the Product Owner forecast when a release could ship, as a range of sprints rather than a single date. It is specific to one team, because each team calibrates its own story points, so it cannot compare teams or measure individual productivity. The Scrum Guide never mentions velocity: it only asks Developers to use their past performance and upcoming capacity when they forecast a sprint.
How do you calculate sprint velocity?
The calculation fits on a sticky note. The rules around it are what make the number trustworthy.
- List the items that are done. At the end of the sprint, keep only the items that meet the team's Definition of Done, the shared standard the Scrum Guide uses to decide when work is complete.
- Add up their estimates. If the team finished stories worth 5, 8, 3 and 5 points, its velocity for that sprint is 21. Atlassian's guide to sprint velocity uses the same method.
- Ignore everything else. A story at 90% counts for zero. Mike Cohn is explicit: teams earn "no partial credit toward their velocity" for unfinished stories (source). The story counts in full in the sprint where it is finished, so the average evens out.
- Keep the original estimates. Do not re-estimate a story after the fact because it turned out harder. Velocity works because estimates are wrong in a consistent way from one sprint to the next.
- Average over several sprints. One sprint is noise. Three to five sprints give a usable baseline.
What does a velocity calculation look like over five sprints?
Here is a fictitious team of five developers working in two-week sprints. "Planned" is what the team selected at sprint planning; "completed" is its velocity.
| Sprint | Planned points | Completed points (velocity) | Rolling average, last 3 sprints |
|---|---|---|---|
| 1 | 30 | 24 | Not enough data |
| 2 | 28 | 30 | Not enough data |
| 3 | 30 | 22 | 25.3 |
| 4 | 26 | 28 | 26.7 |
| 5 | 28 | 26 | 25.3 |
The same data can be read three ways:
- Simple average over five sprints: (24 + 30 + 22 + 28 + 26) ÷ 5 = 26 points.
- Rolling average over the last three sprints: (22 + 28 + 26) ÷ 3 ≈ 25.3 points. Each new sprint pushes the oldest one out, so the figure follows real changes in the team without overreacting to a single sprint.
- Range: the team completed between 22 and 30 points per sprint. That spread is normal: Mike Cohn observes that velocity "bounces around in about a plus or minus 20% range" (source).
For sprint 6, this team should plan around 25 or 26 points, not 30. Planning to the best sprint means carrying work over most of the time. The gap between planned and completed points deserves attention too: when a team keeps finishing less than it planned, the problem is the planning, not the developers.
Why three to five sprints? With fewer, one unusual sprint dominates the average; with many more, it describes a team that no longer exists. A brand-new team has no velocity yet: it plans from capacity, described below, and starts measuring.
What is the difference between velocity and capacity?
Velocity looks backwards: it is what the team completed. Capacity looks forward: it is how much time the team actually has in the next sprint, once leave, public holidays, training and on-call duty are taken out. The Scrum Guide puts both side by side: the more the Developers know about "their past performance, their upcoming capacity, and their Definition of Done", the more confident their sprint forecasts.
| Velocity | Capacity | |
|---|---|---|
| Looks at | The past: what was completed | The future: the time available |
| Unit | Story points per sprint | Person-days or hours |
| Comes from | Done items of recent sprints | The team calendar for the next sprint |
| Main use | Forecasting releases over several sprints | Adjusting the plan for the next sprint |
| Changes when | The team, the scale or the Definition of Done changes | Someone is on leave or a holiday falls in the sprint |
The two combine naturally. Mike Cohn suggests scaling the average velocity by the working days available: predicted velocity = average velocity × (planned working days ÷ average working days) (source). Our example team usually has 50 working days per sprint (5 people × 10 days). If sprint 6 includes a public holiday and a week of leave, it drops to 40 days: 26 × 40 ÷ 50 ≈ 21 points.
For the sprint itself, Cohn goes further. Because velocity is "simply too variable to be useful in the short term", he prefers capacity-driven sprint planning: the team selects items one at a time, breaks them into tasks, stops when the sprint feels full, then checks the total against its velocity. In his words, velocity is "useful in the long term, not the short term": its real job is release planning.
How do you forecast a release with velocity?
Forecasting is where velocity earns its keep, as long as you give a range. Mountain Goat Software's forecasting guide sums it up: "A single average feels precise, but it hides normal team variability." It describes two calculations, one per question.
Fixed scope: when will it be done? Divide the remaining work by the high and low ends of the velocity range. Our team has 160 points left in the release:
- best case: 160 ÷ 30 ≈ 5.3, so 6 sprints;
- worst case: 160 ÷ 22 ≈ 7.3, so 8 sprints.
With two-week sprints, the forecast is "12 to 16 weeks", not "6.2 sprints".
Fixed date: what will be done? Multiply the number of sprints left by each end of the range. With 5 sprints before a trade show: 5 × 22 = 110 points and 5 × 30 = 150 points. The Product Owner can tell stakeholders that the first 110 points of the ordered backlog are very likely, the next 40 are possible, and anything beyond 150 will not make it.
Present the range with its assumptions (same team, same scale, current scope) and update it every sprint: as the same guide puts it, "A forecast is not a commitment." For a statistical range, Mountain Goat Software's free Velocity Range Calculator needs at least five past velocities. To turn the sprint range into person-days and a budget, see our comparison of story points vs person-days.
What makes velocity go up or down?
A change in velocity is a question, not a verdict. The usual causes:
- Team changes. A newcomer slows the team for a few sprints; a departure removes capacity and knowledge.
- Availability. Leave, training and on-call duty reduce capacity: adjust the plan as shown above.
- Unplanned work. Incidents, urgent bugs and support requests eat into the sprint. If they keep coming back, reserve capacity for them.
- Technical debt and dependencies. Fragile code and waiting on other teams slow every story; Atlassian lists both complexity and dependencies among the factors that move velocity.
- Process changes. A new Definition of Done, sprint length or scale changes what a point means: start a new baseline.
- Estimation drift. Without stable reference stories, estimates slowly inflate, and velocity rises while the real output stays the same.
A slow rise over several months usually means the team is genuinely improving. A sudden jump with no explanation is more often a sign of inflating estimates.
What are the most common velocity mistakes?
Most velocity problems come from using it for something it was not designed for.
| Anti-pattern | What goes wrong | Do this instead |
|---|---|---|
| Velocity as a target or KPI | Estimates inflate to hit the number | Use velocity for planning only |
| Comparing teams | Each team has its own scale, so the ranking means nothing | Compare a team only with its own past sprints |
| Converting points to hours | Estimates depend again on who does the work | Convert at team level, through velocity and capacity |
| Counting partial credit | Velocity looks higher than what is really done | Count done items only |
| Planning to the best sprint | Work carried over most sprints | Plan to the average or slightly below |
| Measuring individuals | People optimize their own points, not the team's result | Keep velocity a team metric |
Velocity as a target. As soon as someone asks for "more points next sprint", the easiest way to comply is to estimate higher. That is Goodhart's law, usually quoted in Marilyn Strathern's words: "When a measure becomes a target, it ceases to be a good measure" (source). Ron Jeffries adds that "Increasing pressure to do more almost inevitably has a bad result."
Comparing teams. Jeffries calls comparing teams on velocity "harmful" (source). Atlassian makes the same point from the other side: since each team estimates on its own scale, velocity cannot be used as a political weapon (source). A team at 40 points is not twice as productive as a team at 20.
Converting to hours. "One point equals four hours" turns velocity into a timesheet, although the hours behind a point vary from one person to another: see what a story point is.
How do story points and Planning Poker affect velocity?
Velocity is only as consistent as the estimates behind it. If the same kind of story is a 3 one week and an 8 the next, the sum means little. Three habits keep estimates, and therefore velocity, stable.
- Estimate as a team, at the same time. Planning Poker has every developer vote privately and reveal together, which limits anchoring and makes the whole team own the estimate.
- Keep the same scale and reference stories. A Fibonacci scale and two or three reference stories keep a 5 meaning the same thing for months.
- Use values that add up. Velocity is a sum, so it needs numbers. T-shirt sizes only feed a velocity once each size is mapped to a number of points.
Whichever tool you use (our comparison of free Planning Poker tools lists the main options), copy the voted estimates into your backlog tool so that velocity is calculated on them. Our guide on how to run a Planning Poker session covers facilitation.
Frequently asked questions
How do you calculate velocity in agile? To calculate velocity in agile, add up the story points of every backlog item that meets the Definition of Done at the end of a sprint. Unfinished items count for zero. Then average the last three to five sprints, and express your forecast as a range between the lowest and highest recent velocities rather than a single number.
What is a good sprint velocity? There is no universally good sprint velocity. Velocity depends on the team's own story point scale, its size and its sprint length, so 20 points can be a lot for one team and little for another. A good velocity is a stable one, because stability is what lets a team plan sprints and forecast releases reliably.
Should bugs count toward velocity? Bugs can count toward velocity if the team estimates them in story points like other backlog items. Many teams prefer not to estimate bugs and reserve part of each sprint's capacity for them instead. Both approaches work. What matters is choosing one and sticking to it, otherwise past velocities can no longer be compared.
Is velocity the same as capacity? No. Velocity measures how much work a team completed in past sprints, usually in story points. Capacity measures how much time the team has available in the next sprint, in person-days or hours, once leave and holidays are taken out. Teams use capacity to adjust their average velocity before planning the next sprint.
How many sprints do you need to measure velocity? Three sprints give a first usable velocity, and five give a more reliable range: Mountain Goat Software's Velocity Range Calculator asks for at least five past velocities. Until then, a new team plans its sprints from capacity, by breaking stories into tasks, and treats its first velocities as measurements, not targets.
Sources
- Ken Schwaber and Jeff Sutherland, The Scrum Guide, 2020
- Mike Cohn, Why I Prefer Capacity-Driven Sprint Planning, Mountain Goat Software
- Mike Cohn, Should You Re-Estimate Unfinished Stories?, Mountain Goat Software
- Mike Cohn, Three Approaches to Estimating the Impact of Holidays and Time Off on Velocity, Mountain Goat Software
- Mountain Goat Software, Agile Planning and Forecasting and Velocity Range Calculator
- Atlassian, Sprint Velocity in Scrum and Story points and estimation
- Ron Jeffries, Story Points Revisited, 2019
- Wikipedia, Goodhart's law
Give your velocity solid estimates
A reliable velocity starts with estimates the whole team agrees on. Create a free Planning Poker session, estimate your next stories together and export the results as CSV or PDF for your backlog tool. No sign-up required. See all the features.
