You Think You Have a Velocity Problem. You Have an Undefined 'Done' Problem

A velocity chart dips two sprints running, and a CTO reads it as decline — the exact number a board will ask about directly. Sometimes that reading holds; not every dip means anything. More often, I find, the chart is reporting something else entirely: not less work happening, but a disagreement about what counts as finished.

The ambiguity is easy to miss because everyone assumes agreement exists. “Done” feels self-evident until it’s tested against a real ticket. Does done mean:

• the code merges?
• it’s tested?
• it’s reviewed by a second engineer?
• it’s deployed?
• it’s monitored for a day without incident?
• it’s documented well enough that someone else could pick it up in six months?

Each of these is a reasonable line to draw, and different people on the same team are drawing it in different places.

I notice this most sharply in teams that have grown quickly after funding. New engineers arrive from companies with different defaults — one background treats “reviewed” as a courtesy glance, another treats it as a hard gate. Nobody wrote either standard down, so the gap doesn’t surface until a ticket gets reopened mid-sprint and two people discover, mid-argument, that they were never operating from the same definition.

That reopening is worth sitting with. A team estimates a sprint’s worth of work, closes most of it, and then a third of those “done” tickets come back — reopened against a criterion nobody had named as a requirement until someone applied it after the fact. And as these compound, velocity measures start to look bad.

This is also where the technical-debt-versus-features tension usually lives. A “done” feature that skipped monitoring or left a shortcut in the data layer isn’t a debt decision anyone consciously made — it’s a definition that quietly narrowed under time pressure.

The obvious response is to add a meeting: a review of completed stories before the review meeting, calendared and chaired, treating the gap as a process problem to be scheduled away. Rarely is that where the leverage sits. What tends to work is standardisation: i.e. naming, for each class of work, what specifically has to be true before it counts as finished, and who is accountable for checking it.

Once that’s visible, the velocity conversation changes shape. A board asking why delivery slowed gets a more useful answer than “the team is working through it” — it gets a specific account of what changed about what counts as complete, and why.

The leverage point is different for every team. Finding it is the work