Velocity and forecasting: how to use story points well

Velocity is the total of the story point estimates for the items a team finishes in a sprint, counting only work that meets the Definition of Done. Taken from several recent sprints and expressed as a range, it is the simplest honest way to forecast how much the team will get through next sprint, and roughly when a release will land.

It is also one of the most misused numbers in agile. Velocity works as a planning tool that belongs to the team, and it stops working the moment someone uses it to compare teams or judge productivity. This guide shows how to calculate it, turn it into a forecast, adjust for capacity and keep it useful.

What is velocity?

Velocity measures how much of the product backlog a team turns into finished work per sprint, in the units the team used to estimate. If a team finishes items estimated at 5, 3, 8, 2 and 13 points, its velocity for that sprint is 31.

Two things about velocity surprise people. First, the Scrum Guide doesn’t mention it, or story points, at all; Scrum.org’s glossary describes velocity as optional, and as something the developers track for use within the Scrum team. Second, velocity only means something next to the same team’s history. A velocity of 31 tells you nothing on its own, but quite a lot when the last five sprints were 28 to 34.

What the Scrum Guide does say supports the idea behind velocity: “Only what has already happened may be used for forward-looking decision making.” Velocity is exactly that, a record of what has already happened, used to plan what comes next.

How to calculate velocity

Add up the estimates of every item that met the Definition of Done during the sprint. That is the whole calculation, but four rules keep it honest:

• Done means done. An item that is 90% finished counts for nothing this sprint. When it is finished next sprint, its full estimate counts then.
• No partial credit. Splitting an unfinished item at the end of the sprint so that half of it “counts” makes velocity look steadier and forecasts worse.
• Keep the original estimate. If an item turned out bigger than expected, don’t re-estimate it after the fact. The surprise is part of what velocity measures.
• Be consistent about what gets points. Decide once whether bugs, spikes and support work are pointed, and stick to it. Any sensible rule works; changing the rule every few sprints doesn’t.

Here are six sprints of history from a team working on an online grocery app:

The average is 29 (174 points over six sprints), but notice how lumpy the numbers are. That is normal. Points land in the sprint where items finish, and real sprints contain sickness, incidents and surprises.

Use a range, not a single number

An average of 29 invites a risky conversation: “So you’ll do 29 points next sprint?” Probably not. Over those six sprints the team delivered anything from 24 to 35, and a range tells the truth about that variation.

A simple way to build one is to average your slowest and fastest sprints separately:

• Slowest three sprints: 24, 26 and 28, an average of 26.
• Fastest three sprints: 30, 31 and 35, an average of 32.

So the team’s velocity is 26 to 32 points per sprint. Mountain Goat Software recommends the same principle: build a range from recent history, roughly three to six months of sprints from the same team, handle outliers with judgement, and present the result as a planning aid, never a promise.

Note Prefer recent sprints to the team’s whole history. Old velocity reflects a different codebase, possibly different people and perhaps a different sense of what a 5 means.

Forecasting a release with yesterday’s weather

Extreme Programming has a name for planning from recent history: yesterday’s weather. Martin Fowler describes it as planning to do as much this iteration as you did last iteration. It sounds crude, but it beats optimism, because it rests on what the team actually delivered rather than what everyone hopes.

The same idea scales up to a release, and the range answers both of the questions stakeholders usually ask.

“When will it be done?” (fixed scope)

Say the grocery team has 160 points left in its delivery slots release. Divide the remaining scope by each end of the range, and round up, because a part-used sprint is still a sprint:

• At 32 points a sprint: 160 ÷ 32 = 5 sprints.
• At 26 points a sprint: 160 ÷ 26 = 6.2, so 7 sprints.

With two-week sprints, the honest answer is “in 10 to 14 weeks”. Most stakeholders can plan with that, and a single date would only have looked more precise.

“What will we have by the deadline?” (fixed date)

Now suppose the date is fixed, four sprints away. Multiply instead: 4 × 26 = 104 points is likely, and 4 × 32 = 128 points is possible. Walk down the ordered backlog and draw two lines. Items in the first 104 points will very probably make it, items between 104 and 128 might, and anything beyond 128 almost certainly won’t.

That gives the product owner a clear choice about what to reorder or cut, weeks before the deadline rather than days.

Allow for growing scope

Backlogs grow as teams learn. If the release has been gaining about 5 points a sprint, the team’s net progress is really 21 to 27 points, and the fixed-scope forecast becomes 6 to 8 sprints. A burn-up chart makes this visible, with one line for completed work and one for total scope.

The Scrum Guide lists burn-ups among the practices for forecasting progress, while reminding readers that they “do not replace the importance of empiricism”. In practice that means re-forecasting every sprint as new data arrives.

Capacity: plan for the sprint you actually have

Velocity describes a typical sprint; capacity describes this one. If people are on holiday or at a conference, the team can’t expect a typical result.

The simplest adjustment uses person-days, compared with a normal sprint rather than a perfect one:

1. Count a normal sprint. Five people over a 10-day sprint is 50 person-days. Your velocity already reflects the usual meetings and support duties within that.
2. Subtract what is unusual. This sprint has a bank holiday on the Monday (5 person-days), and Priya is on leave for 3 days. That leaves 42 person-days, or 84% of normal.
3. Scale the range. 84% of 26 to 32 points is roughly 22 to 27 points.
4. Plan towards the lower half. Select about 22 to 24 points of work for the sprint goal, and keep the next ready items in order in case the sprint goes well.

Resist converting points into hours to prove the plan fits. Velocity already measures what the team really finishes after meetings, reviews and interruptions, while plans that count every available hour assume nobody is ever interrupted. Our guide to sprint planning shows how capacity feeds into choosing a sprint goal.

What changes velocity?

Velocity moves for many reasons, and most have nothing to do with how hard anyone is working:

• Team changes. A new joiner usually lowers velocity for a few sprints while others help them settle, then raises it. Someone leaving takes knowledge with them.
• Sprint length. Velocity is per sprint, so after a move from two-week to three-week sprints the old numbers no longer apply directly.
• A stricter Definition of Done. Items sized under the old definition now hide extra work, and new steps are slow until they become routine. See Definition of Ready and Definition of Done.
• Unplanned work. Incidents, urgent requests and support load all compete with planned items.
• Technical debt and unfamiliar territory. Fragile code or a new domain slows everything, and the slowdown shows in velocity before anyone names it.
• Estimate drift. Over months, a team’s “5” can quietly grow or shrink. Re-anchoring on a few reference stories keeps the scale steady.
• Story size. Big stories make velocity lumpy because they land in one sprint or the next. Splitting stories smooths it out.

One thing that doesn’t change velocity in any useful way is pressure. Ask a team to “get velocity up” and the numbers will rise, mostly because estimates inflate, while the amount of finished, valuable work stays about the same.

On planningpoker.org With a free Laya account, in sessions on a Laya board or a Jira board, SprintPoker’s Reference Issues and Matching Issues show items your team has already estimated, so each new item can be compared with agreed sizes. That keeps a 5 meaning the same thing from sprint to sprint, which is what makes velocity worth tracking.

Why velocity must never compare teams or measure productivity

Every team builds its own scale from its own reference stories, so one team’s 5 may be another team’s 2. Comparing velocities across teams is like comparing prices without knowing the currency. A team with a velocity of 60 is not twice as productive as a team with 30; it may simply use bigger numbers for the same work.

Turning velocity into a productivity target does further damage:

• Points inflate. This is Goodhart’s law, usually summed up as “when a measure becomes a target, it ceases to be a good measure”. Last year’s 3 becomes this year’s 5, and velocity rises while output doesn’t.
• Quality gets quietly cut. Under pressure to finish items, testing and reviews get trimmed, and the cost comes back later as bugs and rework.
• Helpful work gets punished. Mentoring, fixing the build pipeline or helping another team earns no points, so people stop doing it.
• It counts output, not outcomes. A team can deliver 40 points of features that no customer uses.

Never track individual velocity either: estimates belong to the team, and so does the work. If leaders need a view across teams, look at outcomes and delivery instead, such as what was released, how long ideas take to reach customers and whether customers noticed.