Sprint Velocity: What It Measures and Why Not to Chase It

Sprint velocity is the total of the estimates for the work a team fully finished in one sprint, usually in story points. Average it over the last few sprints and you get a rough guide to how much the team can take on next time. That is all it is for. Velocity is a planning aid for one team, measured after the fact; it is not a productivity score, it cannot be compared between teams, and the moment anyone is asked to raise it, the estimates quietly inflate and the number stops meaning anything. If your items are roughly similar in size, a simpler count of finished items per week, called throughput, forecasts about as well with no estimating at all.

Whether you need points in the first place is its own question, answered in do you need story points. This piece assumes you already have a velocity number and asks what to do with it.

What sprint velocity measures

The Agile Alliance glossary↗ (opens in a new tab) defines it simply: at the end of each iteration, the team adds up the effort estimates of the user stories it completed, and that total is its velocity. Only finished work counts. Its example: two stories of 2 points each are done, and a 3-point story is 80% done, so the velocity is 4, not 6.4.

Velocity is not part of Scrum. The 2020 Scrum Guide↗ (opens in a new tab) says that the more the Developers know about their past performance, their upcoming capacity and their Definition of Done, the more confident they will be in their Sprint forecasts. It does not name velocity, story points or any particular measure of past performance. Velocity is one common answer to that sentence, not a requirement of it.

How to calculate sprint velocity

1. At the end of the sprint, list the items that meet your Definition of Done. Partly done items count as zero.
2. Add up their estimates, using the estimates they had when the sprint started, not numbers revised afterward.
3. Record that total for the sprint.
4. For planning, take the average, or better, the range, of the last three to six sprints of the same length.

Sprint   Committed   Finished
1           30          21
2           28          26
3           32          18    two people out sick
4           26          25
5           30          27
6           28          24

Average finished: 23.5 points per sprint
Range: 18 to 27. Plan around 22 to 25, not 30.

The range is more honest than the average. A team that finished between 18 and 27 points should hear “somewhere in the low to mid twenties”, not “23.5”.

What Jira and Azure DevOps count

Tools calculate velocity slightly differently, and the details change the number. Atlassian’s Jira documentation↗ (opens in a new tab) says its velocity chart shows, for each sprint, the total estimate of work in the sprint when it begins and the total completed when it ends, and that velocity is the average of the completed totals over the last several sprints. Estimates on sub-tasks are not included, only those on parent items, and stories added or re-estimated after the sprint starts are not included in the commitment total.

Microsoft’s Azure DevOps velocity documentation↗ (opens in a new tab) lets a team choose between the sum of an estimate field and a plain count of work items completed. It always credits velocity to the sprint in which an item was completed, whatever sprint it was planned for, and it warns: use velocity to aid in determining team capacity, but don’t confuse it with key performance indicators.

How velocity gets misused

Most of the damage comes from treating a planning aid as a performance measure. The Agile Alliance lists several of these as pitfalls:

• Setting a velocity target. Velocity is measured, not set. Ask for more and you get bigger estimates for the same work, because points are the team’s own unit and cost nothing to inflate.
• Comparing teams. Two teams’ points are different currencies. A team with a velocity of 60 is not twice as productive as one with 30.
• Individual velocity. Points are a team measure. Splitting them per person invites people to optimize their own number instead of helping finish the sprint.
• Counting partly done work. It makes the chart look steady and hides the stories that never quite finish.
• Treating a drop as a failure. A lower number after someone left, a holiday, or a hard production incident is information, not a problem to explain away.
• Using it as a deadline. Dividing the points left by the average velocity gives a rough range of sprints, not a date to promise a customer.

The pattern behind all of these is familiar: once a measure becomes a target, people change what they report rather than how they work. Velocity is especially exposed to this because the team controls both the numerator and the unit.

Throughput as an alternative

Throughput is the number of items finished per unit of time. The Kanban Guide↗ (opens in a new tab) makes it one of four required flow metrics and defines it as an exact count of work items finished. It needs no estimates, it cannot be inflated by re-estimating, and anyone can check it by counting.

• It works when items are roughly similar in size. The way to get there is to split anything large before it starts, which also shortens cycle time.
• It forecasts the same way velocity does: items left divided by items finished per week gives a range of weeks.
• It suits teams that do not work in sprints at all, since it is counted per week rather than per iteration.
• In a sprint, it answers the same Scrum Guide question about past performance. Bring “we finished 9 to 12 items in each of the last four sprints” to the sprint planning meeting.

Velocity still has a place where items genuinely vary a lot in size and cannot sensibly be split, and where a team keeps its estimating habits stable for months. Outside that, most small teams get the same forecast from throughput with less talk. Add cycle time and work item age, covered in cycle time vs lead time, and you can see not only how much finishes but how long it takes.

If you keep velocity, keep it healthy

• Report it as a range, never a single figure.
• Keep it inside the team. Share forecasts outside, not the raw number.
• Never ask for it to go up. Ask what got in the way instead.
• Re-baseline after the team changes, and say so, rather than comparing across the change.
• Look at the committed-versus-finished gap. A team that routinely commits to 30 and finishes 24 needs to commit to less, not work harder.

Counting throughput on fenbs

fenbs has no sprints, no story points and no velocity chart. Each task has an optional size from XS to XL, where XL means too big, split it, and sizes are never added up into points. What fenbs gives you is the raw material for throughput:

• History records every move with who made it, a person or an AI assistant, and how long ago, so you can count the tasks moved into Completed each week.
• A task in Completed records how it ended, such as Completed, Won’t fix or Duplicate, and the Insights panel’s Completed figure counts only tasks that were actually built. Count the same way for throughput.
• An AI assistant connected over MCP can list finished tasks with fenbs_list_items filtered to the done lane, and set a size with fenbs_update_item when it proposes a split.

If your team depends on sprint velocity reports generated for you, a dedicated Scrum tool will serve you better. If a weekly count is enough, the board and a small spreadsheet will do.