How velocity gets misused, and what it is actually for

A manager asks why Team A delivers 60 points a Sprint and Team B only 35. The honest answer is that the numbers mean nothing side by side, but the question has already done its damage. Both teams now know that someone is reading their velocity, and a number that is being read tends to rise whether or not any more work is getting done.

What velocity is

Velocity is a record of how much a team has finished in past Sprints, written in whatever unit that team uses to size work, usually the story points covered in story points and planning poker. The Agile Alliance's glossary describes it plainly: at the end of each iteration the team adds up the effort estimates of the stories completed, and that total is the velocity. Knowing it, the team can revise its estimate of how long the work will take, assuming velocity over the remaining iterations stays about the same. The glossary calls this generally an accurate prediction, even though rarely a precise one.

Here is an illustrative example. A team finishes 24, 27 and 25 points in its first three Sprints, so its velocity is about 25. If the stories it hopes to complete for the first release add up to 300 points, that is roughly twelve Sprints of work, and the honest way to say it is "about twelve, give or take two or three".

That is the whole idea. You look at what happened, and you let it inform what you expect to happen. The Scrum Guide does not define velocity, and it does not need to. It says 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. Velocity is one way of keeping that knowledge in a form people can use.

What it is good for

Used by the team that produced it, velocity does two useful jobs.

It sets a sensible starting point at Sprint Planning. If the last three Sprints finished 24, 27 and 25 points, selecting 40 points needs an explanation, and selecting 25 does not. The number does not decide anything. It prompts the question "what is different this time?", which is where the real conversation is.

It gives a rough long-range forecast. A Product Owner who has a ranked backlog and a stable velocity can say, with suitable hedging, how much of it is likely to be done by a date. The forecast is a range, not a promise, and it improves with every Sprint of data.

Both uses depend on the same conditions: the team has been stable, the Sprint length has stayed the same, and the points mean the same thing from one Sprint to the next. The SBOK® Guide makes the last condition explicit when it warns against changing the Sprint length from one Sprint to the next, because previous velocities may become useless for forecasting. That is one more reason to keep the Sprint length steady.

Four ways it goes wrong

Comparing teams

Points are a private currency. One team's 5 is another team's 13, because each team sized its own work against its own baseline. The Agile Alliance puts it flatly: there is no meaningful comparison of velocity between different teams, since teams may have different approaches to estimation. The comparison also punishes the honest team. If two teams are both asked to explain a low number, the one that reports its real figure loses to the one that quietly inflated its estimates.

Rating people

Velocity belongs to the team. The Agile Alliance notes that only the aggregate velocity of the team matters, and that the phrase "individual velocity" is meaningless, because a team is a mechanism meant to yield more than the sum of its parts. A Sprint's output comes from the interactions of everyone on it, including the person who spent two days unblocking others and finished no points of their own. Dividing a team's total by head count and treating the result as a personal score rewards the developer who takes the easy items and penalises the one who reviews, mentors and removes obstacles. In a team that holds each other accountable as professionals, as the Scrum Guide expects, that is the opposite of what you want.

Setting targets

Once a number becomes a target, it stops being a measurement. "We need to be at 50 by the end of the quarter" invites the cheapest route to 50, and the cheapest route is to re-label the same work. Stories grow from 3 points to 5. Tasks that used to be part of a story become stories. The chart goes up and the product does not move.

The glossary's wording is worth keeping: velocity is a measurement made after the fact. Though it can help plan ahead, it is not itself a budget or a forecast, and phrases such as "setting the velocity" reveal a basic misunderstanding.

Treating it as a commitment

A forecast of 25 points does not oblige the team to deliver 25, any more than a weather forecast obliges the sky. When a team is held to its average as a minimum, the sensible response is to forecast lower next time. Then planning becomes a negotiation about the number instead of a conversation about the Sprint Goal.

A worked example

Here is an illustrative team, not a real one. Over four Sprints it completes 21, 28, 24 and 12 points. The last figure looks alarming until the team explains it: one Developer was away for the whole Sprint, a public holiday cut two days, and a production incident took a third person for a day. The capacity was roughly 60 percent of normal, and 12 out of 20 is about what that predicts.

Three responses are possible.

• The misuse. "Velocity dropped by half. What went wrong?" The team learns that explaining a low number is costly and starts padding.
• The blind average. Take the four numbers and plan the next Sprint at 21. This ignores that the 12 had an obvious cause.
• The use it was built for. Note the capacity, set the 12 aside as an outlier with a reason, and plan the next Sprint from the typical 24 to 28 range, adjusted for who is actually there.

The third response takes more thought than a formula and gives a better forecast. It is also the one that keeps the team telling the truth about its numbers.

Questions worth asking about any velocity figure

• Which team produced it, and over how many Sprints?
• Did the team, the Sprint length or the sizing approach change in that time?
• Who is reading it, and what are they going to do with it?
• Is the Definition of Done the same in every Sprint? If "done" quietly got weaker, the number rose and the product got worse.

If nobody can answer the last two, the figure is likely to cause more harm than the guess it replaced.

Alternatives when points are not helping

Some teams find that story points add ceremony without adding accuracy. The Scrum Guide mentions burn-downs, burn-ups and cumulative flows as practices that help forecast, and adds that none of them replaces empiricism: in a complex environment, only what has already happened can inform what you decide next. A team can count finished items per Sprint, which removes the debate about sizes altogether and works well when items are roughly similar in size. What matters is that the measure belongs to the team and is used for planning.

How to practise it

Reading about velocity is easy. Feeling the pull to inflate it is harder to teach. In the simulator you commit a team to a Sprint against a known capacity, and you find out what happens when you take on more than that.