Defining done

In standup, someone says they're done with a task, and nobody questions it, because the word sounds self-evident even though it isn't. 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 actually live and a real user has touched it. That's 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's that two people use the same word for different things and don't notice until the gap turns into a cost later on.

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 won't ship without. It covers things like code reviewed, tested to an agreed bar, documented, and deployed, and it holds for every story, not just this one. It's a good practice, and if your team doesn't have one, you should write one. But it only answers a single question: did we build the thing to our engineering standard? It treats meeting that bar as the same as being complete, and 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's live and clears the bar, and it's the one the Scrum checklist covers.
• Outcome-done asks: did it work? The thing it was built to cause actually 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 isn't a higher grade of ship-done, and learn-done isn't the honours track; they're three different questions, and for any given piece of work one of them is the one that matters. The mistake is to treat them as rungs you'd climb higher on if you only had the time, when most work should stop at ship-done and asking for more is just waste.

Most teams have written down only the first one and assume the other two take care of themselves. You can hear it in the phrase people reach for when they sense something missing: "done done." It's telling, because even that phrase names only two rungs: "done" means code-finished, and "done done" means actually-shipped. The everyday vocabulary stops 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 doesn't reach this far down. Done is usually clear for a release: ship this set of features, tested, by this date. It's much less clear for one person's task, and that's where two people quietly end up meaning different things by it.

So make a rule: "done" can't 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, like "done means deployed and verified," not "I finished the code" or "I opened the pull request." That phrase belongs in the ticket or the team's standup norm, not just in someone's head, because someone's head is exactly where two meanings drift apart.

This isn't 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 what actually shipped, who builds the dashboard, and who watches the metric after release. Otherwise "done" just marks the moment the spec left their hands, and everything after that belongs to no one.

The cost of skipping this is usually small and undramatic. 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 wasn't. Nobody was careless; two people just 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 don't always want outcome-done or learn-done, which is the whole point of calling them a menu. For a reversible, low-stakes change like a copy tweak, a config flag, or 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 like a new product surface, a costly migration, or 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, so it isn't relitigated at the end when everyone already has a stake in the answer.

Give each question an owner

Naming the question is only half of it. Each one also 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's 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, because an un-owned question is an abandoned one. It falls back to ship-done every time, for one plain reason: ship-done is the only one that already has a checklist 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 doesn't 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.

This is easy to misread. The team usually hasn't failed a quality bar, and the code might be excellent; what's happened is that they've swapped the question the work was meant to answer for an easier one. Insisting that a bet you framed around outcomes still gets judged on outcomes, even when it would be more comfortable to call it shipped and move on, is the leader's job here.

There's a second reason to hold that line. When someone tells you a task is done and you take the word at face value, you've taken on their private idea of "done" without ever checking it. That was always true, but there's more of it now, because more of the "done"s you hear come from work you didn't watch happen. Do the same thing this whole piece has been about: treat "done" as a claim you check against an agreed definition, rather than a status you file. The checking is the part that's actually done.

Who owns what

One distinction matters here, because it's easy to hear all of this as "the leader writes the definition," and that's wrong. The team owns what goes on each checklist: what's on the ship list, what counts as verified, where the bar sits. That's 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, not just shipping, and here's who watches the number" is a direction call rather than a line on a checklist, and it's the part that gets skipped, because the checklist feels like the whole job.

There's a fourth thing "done" can mean, worth a mention even though it really 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.

Until someone asks which question it's answering, "done" goes on meaning whatever each person privately needs it to mean.