Defining done

In standup, someone says they are done with a task, and nobody questions it, because the word sounds self-evident even though it is not. For the person who said it, "done" might mean the code is written, or the pull request is open, or the change merged and deployed, or QA signed off, or the feature is live and a real user has touched it. That is a wide range of meanings for one word, and the standup moves on as if everyone heard the same one.

The trouble with "done" is rarely that a team sets the wrong bar. It is that two people use the same word for different things and do not notice, because noticing has a price: asking what somebody means by "done" makes you sound pedantic in a meeting that was moving along fine, while the gap you would have caught costs nothing until weeks later. So the question goes unasked, and the gap turns into a cost on its own schedule.

The usual answer to this is the Definition of Done, the checklist that comes out of Scrum: a written standard the whole team agrees on and will not ship without. It covers things like code reviewed, tested to an agreed bar, documented, and deployed, and it holds for every story rather than being renegotiated per task. It is a good practice, and if your team does not have one, write one. But it answers a single question, did we build the thing to our engineering standard, and it treats clearing that bar as the same as being complete. It says nothing about whether the thing worked, or what anyone learned from it.

Name the three definitions of done

There are three definitions of done, and each answers a different question.

• Ship-done asks: did we build it? It is live and clears the bar, and it is the one the Scrum checklist covers.
• Outcome-done asks: did it work? The thing it was built to cause happened: people adopted it, the conversion moved, the support tickets dropped.
• Learn-done asks: did we learn? You got the thing the work was supposed to teach you, whether or not it succeeded.

These are a menu rather than a ladder. Outcome-done is not a higher grade of ship-done, and learn-done is not the honours track. They are three different questions, and for any given piece of work one of them is the one that matters, so treating them as rungs you would climb if only you had the time gets it backwards: most work should stop at ship-done, and asking for more from it is waste.

Most teams have written down only the first one and assume the other two take care of themselves. You can hear the gap in the phrase people reach for when they sense something missing: "done done," with the emphasis doing the work a definition should be doing. Even that phrase only names two rungs, "done" for code-finished and "done done" for shipped for real. The everyday vocabulary runs out at ship-done, with no common word for "and it worked," let alone "and we learned something."

Make "done" specific for each task

The checklist does not reach this far down. For a release, done is clear enough: ship this set of features, tested, by this date. For one person's task it is much less clear, and that is where two people quietly end up meaning different things by it.

So make a rule: "done" cannot stand on its own. In a standup, in the ticket, in a status update, it has to point to a checkpoint the team already agreed on ("done means deployed and verified") rather than to wherever the speaker happens to have stopped ("I finished the code," "I opened the pull request"). The phrase belongs in the ticket or in the team's standup norm, because someone's head is exactly where two meanings drift apart.

This is not only an engineering problem. A product manager who treats "done" as "spec handed over" has the same gap. The definition has to name who checks that the thing shipped, who builds the dashboard, and who watches the metric after release, because otherwise "done" marks the moment the spec left their hands, and everything after that belongs to no one.

The cost of skipping this is rarely dramatic, which is part of why the habit survives. Someone calls a task "done" in standup, meaning the code is finished. Deploying it was never written into anyone's definition of done, so it sat there unowned, and for three days the team thought the feature was live when it was not. Nobody in that story was careless. Two people held different ideas of what "done" meant, and the work slipped through the gap between them.

Pick which question the bet is judged on

You do not always want outcome-done or learn-done, which is the whole point of calling them a menu. For a reversible, low-stakes change (a copy tweak, a config flag, a small internal tool) ship-done is the right and sufficient question, and building a dashboard to check whether the copy tweak "worked" is gold-plating, an answer to a question nobody asked. For a risky or expensive bet (a new product surface, a costly migration, a feature the whole quarter rests on) learn-done is the entire point, and stopping at ship-done wastes the bet: you spent the money and never collected the lesson.

The feature factory is what choosing wrong looks like at scale: a team shipping feature after feature, efficiently, convinced all that motion is producing outcomes when nobody ever set the work up to be judged on outcomes at all. They answer "did we build it" over and over and tell themselves they answered "did it work." Someone has to make this call up front, while the work is being framed, because by the end everyone has a stake in the answer and the question gets relitigated in whichever direction saves face.

Give each question an owner

Naming the question is only half of it. Each one creates follow-up work, and that work needs an owner. If the bet is judged on outcomes, someone has to own the dashboard and the check after release; if it is judged on learning, someone has to own writing down what was learned in a form the next person can use. Skip that and the question quietly dies, and it always dies in the same direction, back toward ship-done, because ship-done is the only question with a checklist already attached, forced on you by the act of building. Nothing forces anyone to read the dashboard or write up the lesson, so unless someone owns it, it does not happen, and the work slides back to "we built it."

Hold the line under pressure

All of this gets worse under pressure. When the quarter tightens, a team lets the work slide toward whichever question is cheapest to answer: an outcome bet gets reported as merely "shipped," a ship bet as "the code's written." Each step down is easier to claim and harder to argue with, so people quietly report the cheapest version they can defend, and nobody in the room has an incentive to make the reporting harder.

This is easy to misread. The team might not have failed any quality bar, and the code might be excellent. What has happened is that they have swapped the question the work was meant to answer for an easier one, and the leader's job here is to insist that a bet framed around outcomes still gets judged on outcomes, even when it would be more comfortable to report it as shipped and move on.

There is a second reason to hold that line. When someone tells you a task is done and you take the word at face value, you have taken on their private idea of "done" without ever checking it. That was always true, but there is more of it now, because more of the "done"s you hear come from work you did not watch happen. Those claims deserve the same treatment as every other "done" in this piece: check them against the definition the team agreed on before you repeat them to anyone else.

Who owns what

One distinction matters here, because it is easy to hear all of this as "the leader writes the definition," and that is wrong. The team owns what goes on each checklist: what is on the ship list, what counts as verified, where the bar sits. That is their craft and their agreement, exactly as Scrum intends. What the leader owns comes earlier and is different: making sure the question gets asked at all, and matching the definition to the bet. Saying "this one is judged on outcomes, and here is who watches the number" is a direction call rather than a line on a checklist, and it is the part that gets skipped, because the checklist feels like the whole job.

There is a fourth thing "done" can mean, though it belongs to its own topic: stopped on purpose. A bet you kill on a trigger you set in advance is done in a real sense, done because you decided it was rather than because it shipped, and that case lives in time-boxing and kill criteria.

A definition of done was never going to carry all of this on its own. It answers the first question well, and the other two get answered only when someone names them while the work is being framed and puts an owner next to the loop.