Agile Velocity: Useful Metric or Vanity Number?

Agile velocity is the amount of work a team finishes in a sprint, usually counted in story points and averaged over the last few sprints. It is a planning tool, not a performance score: it tells you roughly how much to pull into the next sprint, and nothing about whether your developers are good.

That distinction is where most teams go wrong. Velocity is honest when it is used for forecasting and dishonest the moment it becomes a target.

How velocity is calculated

The maths is deliberately simple:

1. At the end of a sprint, add up the estimates of every story that met your definition of done.
2. Ignore partially finished work. A story that is 90% done counts as zero this sprint.
3. Average the last three to five sprints to smooth out holidays, sick days and surprise production issues.

If your last four sprints delivered 21, 26, 18 and 24 points, your working velocity is about 22. Plan the next sprint around that, not around the best sprint you ever had.

Where velocity earns its keep

Velocity is genuinely useful in three situations:

• Sprint planning. It stops the team committing to 40 points when history says 22. See our guide to sprint planning for how to pair it with real capacity.
• Release forecasting. If a release scope adds up to 110 points and you average 22, you are looking at five sprints, give or take. That is a far better conversation starter than a guess.
• Spotting disruption. A sudden drop is a signal worth asking about. Maybe the team spent a sprint firefighting, or the stories were badly split.

Running sprints right now? See how Flow handles boards, sprints and burndown together. Get started with Flow →

When it turns into a vanity number

Velocity breaks as soon as anyone outside the team starts comparing it. Story points are relative to the team that estimated them, so one team's 30 is not "better" than another team's 15.

Watch for these warning signs:

• Estimates creep upwards while delivered features stay the same. That is point inflation, and it happens when people feel judged by the number.
• Stories get closed early and reopened later so they count this sprint.
• Managers ask for velocity to "go up" every quarter. A stable velocity is a healthy one.

Pair velocity with a burndown chart and you get a better picture: velocity shows the outcome, burndown shows how the sprint actually unfolded day by day.

What to measure alongside it

On its own, velocity hides quality problems. A team can hit its number while shipping bugs that come back next sprint. Keep an eye on failed tests, reopened tickets and how much unplanned work crept in. Those tell you whether the points delivered were real.

How Flow helps

Jira has a mature velocity chart built into its Scrum boards, and teams with deep Jira habits often stay for that reporting. If you are weighing up a Jira alternative that keeps the planning side but connects it to testing and releases, here is how Flow approaches it:

• Sprints you can start, complete and bulk-complete, so the boundary of each sprint stays clean and your numbers are not skewed by stragglers.
• Project reporting with key figures, burndown, sprint and time views, so velocity is read in context rather than as a lone number.
• Project health scoring in Livex Flow, which flags delivery problems across five areas and links each finding to the exact tickets, so a dip in output comes with a reason.
• Test runs with pass/fail per ticket, so you can see whether "done" work actually survived QA.