Scrum Velocity: What It Tells You and What It Does Not

Scrum velocity is the amount of work a team finished in recent sprints, usually an average of completed story points. It tells you what this team has been able to get to done under its current conditions. It won't give you a release date or a productivity score, and it can't tell you how a different team would handle the same backlog.

Teams use it because sprint planning needs a number grounded in history. A backlog full of estimates is a wish, while velocity records what actually crossed the line. Treat it as a forecast input for the next one or two sprints, and stop asking it questions it can't answer.

What scrum velocity actually measures

Velocity is completed work per sprint. Only items that meet the team's definition of done count. Work that was started, "almost done," or carried over stays out of the total for the sprint it was planned in. It counts in the sprint where it finishes, if it finishes.

Most teams sum story points, and some sum ticket counts. The unit matters less than using the same one, with the same sprint length, every time. A three-sprint average is the usual window. Two sprints is noisy, and by eight you start mixing an old team shape with the team you have now.

The Scrum Guide does not require velocity. Scrum requires a sprint goal, a sprint backlog, and a done increment. Velocity is a common add-on that many teams use, but it isn't one of the required artifacts.

The number reflects the scope that reached done, the drag from interruptions and bugs, and whoever was actually around that sprint. It isn't a judgment of the team. A sprint at 24 points after a production incident doesn't mean the team got worse than in a quiet 34-point week. It was just a different week.

A worked example

These figures are illustrative, not a benchmark.

A team of six engineers and one designer plans in two-week sprints and estimates in story points. Their last four sprints closed like this:

Sprint	Points planned	Points done	Notes
12	34	28	One engineer out for a week
13	30	31	Quiet sprint, one small incident
14	32	22	Two-day production issue
15	28	29	Full team, no incidents

Points done average (28 + 31 + 22 + 29) / 4 = 27.5. Rather than quoting a falsely precise total, call it about 28, with a recent spread from 22 to 31.

Sprint 16 has the same headcount as sprint 15, and nothing unusual is booked. A commitment near 28 points matches history. A commitment of 34 repeats the sprint 12 plan, which the team did not finish. If one engineer is on leave for the whole sprint, scale the range down first, since a six-person history doesn't describe a five-person sprint.

Use that range in sprint planning as a capacity check once the sprint goal is clear. The goal decides which items matter, and velocity decides how many of them fit.

Two details in the table are easy to miss. Sprint 14's unfinished points aren't "lost velocity"; they count only in the sprint where they reach done. And the planned column is not velocity. A team that averages what it hoped to do is measuring optimism.

Story points and the chart

Story points are the usual input. They express relative size as this team sees it today, covering effort, risk, and what is still unknown. They aren't hours, and they aren't comparable across teams. A "5" here is a different amount of work from a "5" on another squad.

That's why you can't add velocities together. If team A finishes 40 points a sprint and team B finishes 18, the department did not deliver 58 of anything a stakeholder can schedule, because the two teams never shared a unit.

Planning poker is one way to produce those points, and it's optional. A team that already agrees quickly can estimate during refinement and spend planning on slicing and the sprint goal. The points still feed velocity as long as the scale stays stable.

Keep an eye on that scale. If the team redefines a "3" mid-quarter, the chart bends for reasons unrelated to delivery. Say so openly and start a fresh window. Don't rewrite old sprints to smooth the line.

A count of done tickets can replace points when the team slices work to a similar size. The same rules apply: finished items only, one definition of done, one sprint length.

What velocity does not tell you

It doesn't give you a date. "We have 120 points left and velocity is 30, so four sprints" is a sketch that ignores the spread. In the example, a bad sprint was 22 and a calm one was 31. A range is the honest output, and a single date is a guess with a calendar attached.

It doesn't measure quality. A team can push the number up by widening "done," skipping review, or closing tickets that still need a follow-up. The chart rises, and the work comes back later as bugs that eat into a future sprint.

It doesn't measure individual output. Velocity is a team measure. Splitting it by person punishes pairing, review, and whoever picks up the ugly bugs. People start estimating to protect themselves, and planning gets worse.

It doesn't prove improvement on its own. A rising line can mean the team got faster, but it can also mean estimates inflated, stories got smaller, or tests were skipped. Read it alongside escaped defects, cycle time, and whether the increment is releasable.

It doesn't describe another team's pace. Different backlogs, definitions of done, and scales make every velocity chart local.

How to use the number

Keep sprint length fixed. Velocity from two-week sprints doesn't become a one-week figure if you cut it in half, because review and release overhead don't scale that cleanly. If you change the length, start a new series.

Average the last three to five sprints. Drop a sprint only when the team agrees it wasn't a real sample, such as a week when almost everyone was at a conference. If you drop every disappointing sprint, the average turns into fiction.

When spillover is expensive, plan slightly inside the average and say why. A sprint planning template should show capacity, the goal, and the committed set as three separate lines. Velocity informs capacity, but it doesn't replace the goal.

Leave room for work that never shows up in the forecast: urgent defects, review comments, and small operational tasks that land after Monday. Teams that fill 100% of average velocity with new scope spill every sprint and then conclude the metric "does not work."

During the sprint, don't quietly restack the backlog so the forecast still looks right. If a story turns out larger than estimated, split it or drop something else. The sprint backlog is the committed set.

At review, record points done, points carried, and a one-line note on anything that distorted the sprint. Those notes keep the next planning session short. Without them, people will invent a story for every dip in the chart.

Where it goes wrong

Putting teams side by side on one dashboard changes how they estimate within a sprint or two. People pad points, avoid shared work, and grab easy items late so the sprint still "hits velocity." The number only means something inside the team that produced it.

A target does the same damage. Once a bonus, a traffic light, or a standing question depends on hitting 30, the team will hit 30. Estimates drift, chores get pointed, and unfinished work gets marked done. Ask what finished instead of whether the number was reached.

Keep committed scope and completed scope separate, too. Planning needs both figures, but the velocity you carry forward is completed work only.

Staffing changes belong in the notes. After a hiring wave or a departure, the old average describes a different team. Keep the history visible, and base the next commitment on sprints that look like the one you're about to run.

Change one input at a time. A new point scale, a new definition of done, and a new sprint length in the same week produce a chart nobody can read. Wait two or three sprints before you compare.

What to put next to it

Velocity answers how much scope finished per sprint. Other questions need other tools.

Cycle time is how long one item waited and how long it took once someone started. Stable velocity with worsening cycle time often means work is stuck in review. Cumulative flow shows which stage is backing up. Throughput (items finished per week) is the point-free cousin of velocity, and it makes a better shared chart when teams won't share a point scale.

Forecasts built from historical cycle time give a range of dates, which is the right shape for "when might this set of tickets be done?" Falrow keeps cycle time percentiles, cumulative flow, and Monte Carlo delivery forecasts beside the sprint record on its insights views. A simpler version is a spreadsheet of recent throughput with a blunt high-low range. Either way, don't turn a single average into a promised day.

Rollover needs a decision. An item that misses the sprint should be pulled next, split, or dropped, and that choice should be written down. If the same ticket rides along for three sprints while velocity looks steady, the number is counting other work and hiding the stuck one. Cycles with reviewed rollover keep that choice on the record, and a line in the planning notes does the same job.

A habit that stays honest

1. Open the last three to five sprints and read points done plus the one-line notes.
2. Adjust for known absences and for holidays inside the sprint.
3. State a range. In the example, that's about 26 to 30, lower if on-call is heavy.
4. Pick the sprint goal first, then pull items that serve it until you're inside the range.
5. Leave space for defects, and write every carryover down before you close the meeting.

An hour is enough when refinement already happened. A tight sprint planning meeting agenda keeps the velocity check to a few minutes, so the rest of the hour goes to slicing and the goal.

Bring a miss to the retrospective only when the sprint landed far outside the range. Ask what changed in the work or the team, and update the notes. Don't edit the history to fit a preferred story.

Used narrowly, scrum velocity is one of the cheapest signals a team can keep. It can't grade people, promise a quarter, or prove a transformation, because none of that was ever in the data.

FAQ

What is scrum velocity?

Scrum velocity is the amount of work a team completes in a sprint, almost always summed in story points and averaged over recent sprints. Only work that meets the definition of done counts. The figure is a planning input for that team, and you can't copy it onto another squad as a standard.

Is velocity part of Scrum?

No. The Scrum Guide requires transparency, inspection, and adaptation, plus the sprint events and artifacts. Velocity is a widespread complement. You can run Scrum and plan from item counts or from cycle time instead. If you do use velocity, keep sprint length and the meaning of "done" stable so the series stays readable.

How many sprints do you need before the average is useful?

Three completed sprints of the same length give a rough range, and five is more stable. A new team, or one that just changed size, should treat early numbers as a draft and commit conservatively. One sprint is a single anecdote, so don't build a quarter plan on it.

Should managers set a velocity target?

No. A target rewards estimate inflation and a loose definition of done. Managers should ask which increment shipped, what is still open, and what blocked the sprint. The team can use its own average as a capacity check, but a required number turns the metric into a score, and then it stops measuring delivery.