Velocity: what it's for and how to calculate it

Velocity is the story points a team completes per sprint, averaged. What it's for, why it breaks the moment it becomes a target, and how to keep it honest.

Velocity is a forecast input, not a KPI. The moment you measure teams on it, it inflates.

Velocity is the average number of story points a team completes per sprint over the last few sprints. That’s the whole definition. It exists for one job: projecting how many sprints a backlog will take to ship, given the team’s actual rate of delivery. Sum the points remaining, divide by velocity, you have a forecast. That is the only thing it does honestly.

Every other use breaks it. “Why was velocity lower this sprint?” turns each retrospective into a defence of the number. “Team A has a higher velocity than Team B” treats two teams’ independent calibrations as comparable when they aren’t. “We need to increase velocity by 20% this quarter” tells the team to make the number go up, and the team will — by sizing the same work bigger, not by doing more of it. Goodhart’s law, running on a two-week cycle.

How to calculate it

Take the points completed in each of the last three to five sprints. Average them. That’s your velocity. Don’t adjust for “exceptional” sprints — the exceptional sprints are part of the signal you’re trying to smooth out. Don’t count carried-over work twice. Don’t count partially-completed stories at all; they get counted in the sprint they actually finish in. The simpler the calculation, the harder it is to game.

Velocity stabilises after a team has been running together for three or four sprints. A new team, a new reference story, a major personnel change — all reasons to throw out the prior number and rebuild from scratch. The number isn’t a property of the technique; it’s a property of this team in this period of time. A team that lost two members yesterday has yesterday’s velocity for a different team.

How many story points per sprint?

Searching “how many story points per sprint” is a category error. There’s no industry number, no “good” number, no per-developer-per-day rate. Velocity is the team’s measured throughput, and the only useful version is the rolling average over the team’s own last few sprints. Fifteen points, forty points, a hundred points — none is right or wrong. They’re calibrated to the team’s reference story.

Velocity over six sprints with two outliers pulling the average above the sustainable rate 0 30 60 points avg 35 actual 29 s1 s2 s3 s4 s5 s6 easy sprint carry-over plan to the teal line, not the orange one
The two easy sprints pull the average above the team’s sustainable rate. Plan to the typical sprint, not the mean.

So use velocity to do three things, and only three: project a date for a known scope (scope ÷ velocity = sprint count); decide what fits in the next sprint (pick stories until they sum to about 80–90% of the recent average, leaving room for the unplanned); and spot when something has changed (a 30% drop is signal worth a retrospective conversation). What you can’t do with it: compare it to another team’s number, use it to grade the team, or convert it to “expected hours per developer per day.” Each of those is the same mistake wearing a different hat.

What goes wrong

The single most common failure mode: a manager reads a velocity number as “how productive is this team?” It gets quoted in status meetings, then compared across teams, then targeted. Within two sprints the team has rebased its sizing to make the number go up — every story now sizes 30% bigger than it used to — and velocity has stopped meaning what it used to. The forecast it was supposed to produce is now wrong.

The second: comparing teams. Two teams sizing the same backlog produce different velocity numbers because they use different reference stories — that’s the whole point of relative estimation. Comparing them is like comparing two thermometers with different zero points. The numbers don’t mean the same thing, and treating them as if they did corrupts both teams’ calibration.

When to re-estimate

Re-estimating completed work breaks velocity. Re-estimating carried-over work is the only honest case.

The question comes up every quarter: “we sized this as a 5, it was actually a 13 — should we update it?” The instinct that says yes is the same instinct that wants every number to be retroactively correct, and it’s wrong. Velocity is the rate at which the team — at the calibration it had at the time — completed work. Going back and rewriting the points rewrites the calibration too, and the forecast that used to work stops working. “The team got faster, so old stories should be smaller” removes the only signal that the team improved. “This 5 turned out to be a 13” is a refinement signal for sizing the next story like it, not a licence to rewrite this one’s history.

The one case where you should re-estimate is carry-over. A story didn’t finish, the sprint is closing, the remaining work moves into next sprint’s commitment. That remaining work is materially different from what was sized at the start — the team has done some of it, found at least one unknown, and has a clearer view of what’s left. Vote it again as if it were new, using the original estimate as a sanity check rather than a constraint.

Normalising velocity across teams

Normalisation is mostly a SAFe ritual to make a portfolio dashboard add up. Resist it unless someone above you genuinely needs that dashboard.

Normalisation gets two or more teams to agree on a shared reference story — usually something like “one person-day of work for an average engineer” — so a 5 on Team A means the same thing as a 5 on Team B, and their velocities can be summed. The technique works: a normalised 5 really does mean the same across the teams that agreed to it. The problem is what you traded for it. You’ve swapped each team’s relative-estimation property for an absolute one — which is estimating duration in disguise — just so a number can be averaged across teams that don’t share a codebase, a stack or a domain.

If a portfolio-level forecast genuinely funds work (not just compares teams), do the normalisation at the rollup layer: have program management keep a per-team points multiplier, calibrated once and revisited rarely, and apply it when the numbers roll up. Each team still estimates against its own reference story; the multiplier turns team velocity into the portfolio’s currency, and refinement meetings never see it. What to push back on: normalisation that starts inside a single team, and normalisation done to make team comparison easier. That second one isn’t a use case — it’s an anti-pattern with a polished name.

Velocity and AI coding tools

Copilot, Cursor, Claude Code. The points don’t change. Velocity does — and only after the fact.

The question shows up in every team that’s used an AI coding assistant for a few months: we’re shipping faster, should we re-size the backlog? Should last quarter’s 3 be this quarter’s 5? The answer is no, because story points were never measuring the thing that changed. Points measure relative complexity and uncertainty; the assistant reduces the keyboard time on a story, sometimes dramatically, but the complexity is unchanged, the unknowns are unchanged, the integration risk and edge cases are unchanged. Re-point a 5 to a 3 because the tool wrote the boilerplate and you’re estimating in hours again.

What changes is velocity. The same team shipping the same kind of work with an assistant ships more points per sprint than it did six months ago — not because the points got smaller, but because the team got faster at turning points into shipped code. That’s the number doing exactly its job, and it rebases naturally over three or four sprints. Keep the team’s reference story recent — one they shipped with the tools they use now — and the calibration already accounts for whatever speed-up exists.

Two things to push back on. “Velocity is up 30%, let’s commit to 30% more” double-counts the improvement: the recent average already includes the AI effect, so don’t scale it again. “Everything got smaller, let’s re-estimate the backlog” is the re-estimation trap above — the stories didn’t shrink, the team got faster, and the forecast already reflects it. Uncertainty is where the tools help least: an assistant speeds up parts of a spike’s investigation, but the thing the spike is trying to learn hasn’t gotten any smaller.

Frequently asked questions

How many story points per sprint is normal?

There’s no industry number. Velocity is your team’s measured throughput — the rolling average of points completed over the last few sprints. Fifteen, forty, a hundred: none are right or wrong, because each is calibrated to a different reference story.

How many story points per sprint per developer?

Don’t compute one. A per-developer rate turns story points back into disguised hours and invites the cross-person comparison the technique is designed to avoid. Velocity is a team number, not a sum of individual quotas.

How many story points are in a two-week sprint?

However many your team has historically completed in a two-week sprint — measure it, don’t target it. Pick stories until they sum to roughly 80–90% of your recent average, and leave room for the unplanned.

What is a good velocity for a scrum team?

A stable one. “Is our velocity good?” is the question that breaks the system — the moment velocity is graded, points inflate and nothing actually ships faster. A good velocity is one you can plan against, not a number that keeps climbing.