Measuring and using team velocity

How to calculate it

Velocity is the number of story points on items the team finished in a sprint — finished by the team's own definition of done, not "in review" or "waiting for deploy".

• Count each item once, in the sprint it completed.
• No partial credit. An 8-point story half done contributes nothing this sprint and 8 next sprint.
• Do not re-estimate at the end because the work turned out harder. That destroys the signal.
• Exclude unestimated work; if a category of work matters, estimate it rather than ignoring it.

Worked example: a sprint completes a 3, two 5s, an 8 and a 2, and leaves a 13 unfinished. Velocity is 23. Next sprint, if the 13 finishes, it counts there in full.

How many sprints before it means anything

One sprint is an anecdote. Three is a hint. Velocity becomes usable at around five or six sprints with a stable team and a stable scale — and it resets whenever the team composition, the scale, or the definition of done changes materially.

Use the range of the last five or six sprints rather than the average. The average hides exactly the variability that makes a forecast honest.

Forecasting with a range

1. Sum the remaining scope in points, including a contingency for work you know will appear.
2. Take the lowest and highest of the last six velocities.
3. Divide the scope by each end to get an optimistic and a pessimistic sprint count.
4. Convert to dates and state the assumptions: scope, team size, no extended absences.

Re-run this every sprint. A forecast that is not refreshed is a promise, and promises made from three-month-old data are how delivery dates get missed quietly.

Planning a sprint with it

Pull to the lower half of your range, not the top. Committing to your best-ever sprint means every sprint ends with spillover, and chronic spillover teaches the team that the plan is fiction.

Adjust for known absences proportionally — two people away for a week out of a five-person team is roughly a 20% reduction — and leave explicit room for support, bugs and review if those are not estimated separately.

What velocity cannot tell you

• Whether one team is faster than another. Scales are calibrated locally; the numbers are not comparable in any direction.
• Whether the team is productive. Shipping 40 points of the wrong feature is worse than shipping 12 of the right one.
• Whether an individual is performing. Velocity is a team measurement; splitting it per person rewards hoarding work and punishes helping.
• Whether quality is holding. Rising velocity with rising defect counts is a warning, not a win.

The moment velocity becomes a target, it stops being a measurement: estimates inflate, stories get split to game the count, and the number rises while nothing improves. If a manager asks for a velocity goal, offer a delivery outcome instead.

Diagnosing a velocity that moves

• Sudden drop. Usually absences, an incident, unplanned work, or a large story that did not finish. Check the sprint's unplanned items first.
• Steady decline. Often growing technical debt, a slowing test suite, or review bottlenecks — the estimate is right and the work really is getting harder.
• Sudden jump. Suspect scale drift or a batch of stories carried over from the previous sprint landing at once.
• Wild swings. Usually story size: a sprint of two 13s finishes or it does not. Smaller stories produce a smoother, more forecastable series.

Keeping the underlying data honest

Velocity is only as good as the estimates behind it, and estimates degrade when nobody can see how they were made. Keeping a record of each round — who voted what, how wide the spread was, what value the team agreed — makes it possible to spot anchoring, scale drift and stories that were "agreed" by one person.

Planner Poker keeps that history per room: every task, every participant's vote, the average, minimum and maximum, and the agreed value, available in the session summary and in your dashboard afterwards.