Definition of Done

"That's done" means different things to different people. To an engineer it means the code is written. To someone checking quality it means the tests passed. To a product manager it means a customer can actually use it. One sentence, three readings, and three people leaving the same meeting with three different pictures in their heads.

The gap shows up about two weeks later. At sprint review the product manager asks to see the notification feature that was reported finished last week, and the engineer says the code is done but it hasn't shipped. Nobody lied, and the schedule slips anyway, because next week's work was already assigned on top of it. Unfinished work piles up underneath a plan that assumed it was finished.

The definition of done (DoD) fixes the meaning of that sentence inside the team before anyone has to use it. Write down the state that counts as finished, keep it where everyone can see it, and "that's done" stops being a personal impression and becomes a report that the list was cleared. Nobody has to trust six individual standards; one list is enough.

What belongs on the list varies by team, but the items usually cluster into four groups.

1. Code — whether someone else has looked at the change. Most teams require at least one code review with a recorded approval. Code review is the step where a colleague reads a change and comments on it before it gets merged.
2. Tests — whether the new behavior is covered, and whether anything that used to work still does. Requiring a clean regression test run is common, since that's the check that catches the second half.
3. Deployment — whether the work reached the environment customers actually use. Leave this out and "built but nobody can use it" counts as finished. Teams that ship features switched off decide here whether shipping in the off state counts.
4. Handoff — whether the change is written down and the people facing customers know about it. A support agent who doesn't know a screen changed turns that change into an incident outside the company.

Three conditions govern what makes the list. It has to read the same to everyone: "is the code clean" splits opinions, "is there at least one approving review" doesn't. It has to apply to every item without exception, because the first exception turns the list into decoration. And it has to be short — a twenty-line list never gets read to the bottom, so most teams land somewhere between seven and ten lines. Anything that can't survive those three conditions is better left out than written down and quietly skipped.

The team doing the work writes it. Handed down from above, it doesn't hold. Whether deployment belongs in the list, whether documentation is mandatory — those depend on circumstances only the people in the work can see. Product managers and designers sit in the conversation, but engineering settles the items, because whether the list gets honored rests with whoever walks through the steps every day. Teams running Scrum usually revise it during the retrospective: add a line for whatever got skipped and caused trouble this cycle, drop a line nobody follows.

Three groups read it. The person finishing a task runs through it last. The product manager receiving the report checks against the same list. And metrics that count only completed work — velocity, the average amount a team finishes per cycle — use it as the cutoff. Mix loose cycles and strict cycles and that average swings too widely to plan against. Three sprints at 32, 30 and 34 support a plan; 12, 40 and 25 support nothing.

A new list shouldn't try to be complete. Start with the three or four things the team already does, then add a line each time something goes wrong. Write the ideal list first and some line goes unmet in week one, and the moment one line is ignored the rest lose their force too.

"This didn't clear the definition of done, so it's not going in this sprint."

The feature works, but one item on the list is still open.

"Let's decide in the retrospective whether deployment belongs in our definition of done."

A proposal to change the list itself.

"The definition of done is the same for every item; acceptance criteria are specific to this one."

Straightening out two documents whose roles were getting mixed.

Pagedeck's engineering team keeps an eight-line list. When Theo reported the notification settings feature finished, Mia went through the list with him and one line was open: the support team hadn't been notified. The feature was live in production, but the people answering questions didn't know the screen had changed.

That item didn't count as done for the cycle and rolled into the next one. In the retrospective the team added a line naming who posts the notice and when. Noa proposed a design item as well, and because it could be judged differently by different people, it went in reworded as "has the screen been compared against the design file once". The wording matters more than the intent here: a line two people can score differently produces an argument rather than a check.

A long list is often read as a high bar. Writing down more checks feels like more care. But a long list makes the checking itself into work, and people start skimming. On a team with a fifteen-line list, the lines that actually get verified are the first few. The rest provide reassurance without preventing anything, which is worse than having no line at all, because the team believes it is covered. If incidents went up after the list grew from eight lines to fifteen, this is usually why. Removing what can't be honored is what keeps the rest alive.

Treating it as fixed once written is the other common mistake. A standard that changes often doesn't feel like a standard. But this document records what the team is currently capable of, so it has to move when that changes. A team before and after automated deployment can't keep the same sentence about shipping. Leave it alone and it fails in both directions: lines that have become trivial eat time every week, and new risks go unguarded until the same incident repeats.