Velocity

For a long time, the only answer to "when will this be done?" was a guess. One engineer would picture the worst case and say two months. Another would picture a good week and say two. Same work, answers four times apart, and nobody listening believed either of them.

Planning meetings kept landing in the same place. Sales would ask whether something could ship by the end of the month, engineering would say they'd try, and a month later everyone would argue about whose fault it was. Without evidence there were no commitments, and without commitments there was no trust.

Velocity exists to put evidence behind that question, and it does it by turning the question around. Instead of predicting how much a team can do, it measures how much the team has actually done over the last few cycles and uses that number for the next plan. The answer comes from the record rather than from whoever felt most confident or most pressured in the room.

Add up the story points of everything finished in a sprint, then average that total over the last three to five sprints.

A story point is a number that describes the size of one piece of work. Size, not time — that distinction is the whole point. A team picks one reference item ("building the login screen is a 3") and sizes everything else against it using values like 1, 2, 3, 5, 8. Hours don't work as the unit because the same task takes different people different amounts of time, which makes the sum meaningless.

The calculation has three steps.

1. Pick out only the work that finished this sprint. Anything still in progress drops out here, no matter how far along it is.
2. Add up the points. Finish five items sized 5, 3, 3, 2 and 1 and the sprint comes to 14.
3. Average the last three to five sprints. Totals of 14, 16 and 12 give a velocity of 14.

Step 1 is where teams get stuck, because "finished" needs a shared meaning. Only work that meets the definition of done (DoD) counts. The definition of done is a checklist the team agrees on in advance — usually something like reviewed, tested, and running in production.

Work that is built but still waiting on review counts as zero and rolls into the next sprint. It's tempting to award 7 points for an 8-point item that's 90 percent there, but partial credit inflates every sprint total, and a plan built on inflated numbers slips again. The rolled-over item collects its full 8 points in the sprint where it actually finishes.

The absolute number means nothing on its own. Story points are a unit each team invents for itself, so one team's 40 and another team's 40 are not the same amount of work. If team A sizes the login screen at 3 and team B sizes the same screen at 8, team B's number will always run more than twice as high without anyone doing more work. Velocity cannot rank teams.

A good velocity is a steady one, not a high one. Three sprints at 32, 30 and 34 support a plan of roughly 32 for the next one. Three sprints at 12, 40 and 25 average out to 26, and that 26 guarantees nothing. What matters about a scale isn't how large the numbers are but whether it reads the same under the same conditions.

Wide swings usually have a cause worth finding. The team changed size between sprints, work was sliced into wildly uneven chunks, or the definition of done was applied loosely in some cycles and strictly in others. Look there before adjusting the number.

This is why a newly formed team can't use velocity right away. Run three to five sprints, wait for the spread to tighten, and only then treat it as a planning input. When the team changes or the sizing baseline is reset, throw out the old average and start collecting again.

"Our velocity has been 32 for three sprints and we just committed to 40. Isn't that a stretch?"

The plan is 25 percent above what the team has actually delivered, so something should come out.

"Don't compare velocity across teams. The point scales are different."

Pushing back on someone trying to use the number for evaluation.

"We don't have a stable velocity yet, so I'll give you a range for the quarter."

Too few sprints have run for the average to be worth trusting.

At Pagedeck this number comes up in every sprint planning session. Once engineering picks the items for the cycle, Mia reads out the total, and if it's noticeably above the recent average the team decides right there what to drop. If the total comes in well under the average she asks why. Someone on vacation or on loan to another team is a fine reason; no reason at all means picking up another item.

The number doesn't make the decision. It starts the conversation. After Mia says "that's 40 against a 32," the people who know the work decide what comes out.

The most common mistake is reading velocity as a productivity score. A higher number looks like more work, which is a natural enough assumption. But the number is a sum of points the team assigns to itself, so it rises the moment sizing gets a little more generous. Start using it for evaluation and the team drifts toward larger estimates for identical work — six months later the number has climbed from 30 to 45 while the same amount of software ships.

Treating it as a target has the same shape. "Let's raise velocity 20 percent this quarter" is a request to move the marks on a ruler. Turn a measuring instrument into a goal and it stops measuring. A team handed that target usually reaches it by slicing the same work into more items and sizing each one a little higher. The next quarter then gets planned against 40 while the software that ships is the same as it was at 32. The thing worth raising is the value the team delivers, and whether that went up is a question for different metrics.