Flocci Projects

HomeAgile answers › What is sprint velocity and how is it calculated?

What is sprint velocity and how is it calculated?

Sprint velocity is the number of story points a team completes per sprint. Calculate it by summing the points of every fully finished story in the sprint, then average the last three to five sprints for a planning number. A team completing 21, 18 and 24 points has a velocity of about 21.

The formula

Velocity equals the sum of story points of DONE stories in the sprint. Half-finished work counts zero, because velocity measures delivery rather than effort. A rolling average over three to five sprints smooths out flu weeks and festival weeks, and that average — not last sprint's raw number — is what you plan against.

Worked example

Sprint 1: the team commits 30 points and finishes stories worth 21, so velocity is 21. Sprint 2 finishes 18. Sprint 3 finishes 24. The average is about 21, so Sprint 4 planning pulls roughly 21 points of backlog even if enthusiasm argues for 30. Over-commitment is the single most common cause of demoralising sprint failure.

What velocity is NOT

Velocity is not a productivity score and must never be compared across teams — points are relative to each team's own estimation scale, so a cross-team comparison measures estimation habits, not output. Inflating estimates to raise velocity simply devalues the unit. Its only legitimate job is forecasting how much this team, estimating this way, ships per sprint.

Tracking velocity without a spreadsheet

Flocci Projects derives velocity automatically: complete a sprint and its Done points become a bar on the velocity trend chart, with the average across completed sprints shown alongside status distribution and per-assignee workload — free on the personal board. ClickUp gates Sprint Points to Business ($12/user/month) and Linear puts Insights on Business ($16/user/month).

Try it on a free Flocci Projects board

Related questions

How many sprints until velocity is reliable?

Three completed sprints give a usable average; five give a trustworthy one. A brand-new team should plan its first two sprints conservatively and let the number emerge rather than setting a target, because a target turns points into a currency people inflate.

Should unfinished stories count partially toward velocity?

No. Counting partial work inflates the forecast and hides the real problem, which is usually stories that are too big or scope that crept. Roll the story into the next sprint; its points count when it is genuinely done.

Is higher velocity always better?

No — a stable velocity beats a high one. Forecasting needs consistency, so a team shipping 20 points every sprint is more valuable to planning than one oscillating between 10 and 35, even though the second team's peak is higher.

More agile answers