A sticky-note character at a whiteboard tracing a line across six sprint columns, pointing at the steady middle rather than the tallest spike.

Team velocity in agile: how to measure and use it (+ free calculator)

Learn what team velocity is in agile, how to calculate it, and how to plan sprints with it, plus a free velocity calculator.

Team 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, taken over the last few sprints. That is 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, and 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 defense of the number. “Team A has a higher velocity than Team B” treats two teams’ independent calibrations as comparable when they are not. “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 rather than doing more of it. That is Goodhart’s law running on a two-week cycle.

One honest caveat before the how-to: the Scrum Guide does not mention velocity. It is a common practice layered on top of Scrum, not a rule of it, which is exactly why it is worth being deliberate about what you use it for.

Free velocity calculator

Here is the fastest way to see velocity in action. Enter the points your team completed in each recent sprint, and, if you want the forecast, the points left in the backlog. The calculator averages your recent sprints and returns a sprint-count forecast, all on this page. No sign-up.

Enter at least one sprint's points to see your velocity.

Team velocity across three sprints with rolling average 0 20 40 21 34 26 avg 27 Sprint 7 Sprint 8 Sprint 9 Forecast: points remaining / velocity = sprints left
Three sprints of 21, 34 and 26 average to a velocity of 27. Divide the points remaining by 27 to forecast the sprints left.

Read the range, not just the average. Your next sprint lands somewhere between your best recent sprint and your worst, so a forecast quoted as a single number carries more certainty than the data does. “Eight to ten sprints” is an honest answer. “8.7 sprints” is false precision wearing a decimal point.

How to calculate team velocity

Take the points completed in each of the last three to five sprints. Average them. That is your velocity.

A worked example, over three sprints:

SprintStory points completed
Sprint 721
Sprint 834
Sprint 926

Velocity = (21 + 34 + 26) divided by 3 = 27 points per sprint.

If the backlog has 210 points remaining, the forecast is 210 divided by 27, which is about 8 sprints. Because the inputs ranged from 21 to 34, the honest version is “seven to ten sprints”, not “7.8 sprints”. Or skip the arithmetic and let the calculator above run it for you.

The rules that keep the number honest: do not adjust for “exceptional” sprints, because the exceptional sprints are part of the signal you are trying to smooth out. Do not count carried-over work twice, and do not count partially completed stories at all. They count in the sprint they actually finish. The simpler the calculation, the harder it is to game.

Velocity stabilizes after a team has been running together for three or four sprints. A new team, a new reference story, or a major personnel change are all reasons to throw out the prior number and rebuild from scratch. The number is not a property of the technique. It is 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.

Using velocity to plan the next sprint

Velocity earns its keep in sprint planning, and the method is short:

  1. Start from the rolling average of the last three to five sprints, never a single sprint’s number, and never your best sprint.
  2. Adjust for known capacity changes. Two people on leave next sprint? A public holiday? Scale the target down proportionally before planning, not apologetically afterwards. Velocity assumes the team that produced it, and next sprint’s team is sometimes smaller.
  3. Commit below the average, about 80 to 90 percent of it. Pick stories until they sum to roughly that, and leave the slack for the unplanned work that arrives every sprint whether you plan for it or not.
  4. Forecast in ranges. For anything beyond the next sprint, quote your best and worst recent sprints as the bounds. Stakeholders can plan around “seven to ten sprints”. They cannot plan around a precise number that turns out to be wrong.

Use velocity to do three things, and only three: project a date for a known scope (scope divided by velocity gives a sprint count), decide what fits in the next sprint, and spot when something has changed (a 30 percent drop is signal worth a retrospective conversation). What you cannot 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.

How many story points per sprint?

Searching “how many story points per sprint” is a category error. There is 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 are 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.

The big mistake: velocity as a performance score

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, which is the whole point of relative estimation. Comparing them is like comparing two thermometers with different zero points. The numbers do not mean the same thing, and treating them as if they did corrupts both teams’ calibration.

Want the arithmetic done for you? Jump back to the free velocity calculator and run your own sprints through it.

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 license 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.

Normalizing velocity across teams

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

Normalization 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 normalized 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 normalization 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: normalization that starts inside a single team, and normalization 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.

Estimate together in TeamRetro

Velocity is only as good as the estimates behind it. TeamRetro Estimations runs planning poker with your team, live or async, so the points you feed this calculator come from the whole team’s judgement, not one person’s guess. Try TeamRetro Estimations, or start with the free planning poker tool.

Frequently asked questions

What is team velocity in agile?

Team velocity is the average number of story points a team completes per sprint, usually measured over the last three to five sprints. It is a planning input, used to forecast how much fits in the next sprint and how long a backlog will take, not a measure of how good the team is.

How do you calculate team velocity?

Add up the story points completed in each of the last three to five sprints and take the average. If your last three sprints completed 21, 34 and 26 points, your velocity is 27. Count only finished stories, in the sprint they finished, or use the free calculator on this page to run the numbers.

What is a good team velocity?

A stable one. There is no benchmark, because every team’s points are calibrated to its own reference story, so 15, 40 and 100 can all be healthy. A good velocity is one you can plan against, not a number that keeps climbing.

Should you compare velocity across teams?

No. Different teams calibrate points against different reference stories, so their velocities are not in the same units. Comparing them is like comparing two thermometers with different zero points. Cross-team comparison also pressures teams to inflate estimates, which corrupts the forecasts velocity exists to produce.

What if we don’t estimate in points, for example we use t-shirt sizing?

You can still track a rough throughput, but you cannot get a true velocity number straight from t-shirt sizes, because sizes do not add up. Two options. Map the sizes to a simple point scale first (for example XS=1, S=2, M=3, L=5, XL=8), total the completed items each sprint, and treat the result as a coarse trend rather than a precise figure. Or, if your items are usually similar in size, count throughput instead: the number of items finished per sprint. Both are rougher than points-based velocity, so read them as direction, not decimals. When you need a real forecast, re-estimate the near-term work in points. See our guide to t-shirt sizing for the size-to-points bridge.

How do we account for work that isn’t recorded as sized items?

Velocity only reflects the work you actually size and track. Support tickets, meetings, interruptions and un-pointed bug fixes still consume capacity, so if a lot of that work is invisible, your velocity will look lower than the team’s real effort and your forecasts will run optimistic. Two honest fixes. Capture the recurring unplanned work as sized items so it enters velocity like everything else. Or reserve capacity for it openly, by committing to about 80 to 90 percent of your average and leaving the rest as slack. Do not back-fill points onto invisible work just to make the number look bigger, because that breaks the calibration velocity depends on.

How do you treat re-work in velocity?

Re-work is real effort, but re-pointing a story that was already counted as done breaks velocity. Treat re-work as new work: create a new item, size it, and count it in the sprint it is completed. Do not reopen the original story and re-estimate it. If re-work keeps showing up, that is a quality signal worth a retrospective conversation, not a velocity adjustment. The forecast stays honest only if each point is counted once, in the sprint the work actually finished.

How many story points per sprint is normal?

There is 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, do not target it. Pick stories until they sum to roughly 80 to 90 percent 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.