Your Definition of Done Is Wrong. - Full Scale

Book Discovery Call

In this articleWhat the definition of done actually says today<br>“Code shipped” is the wrong finish line<br>The old definition of done built an assembly line<br>Real done is when the customer succeeds<br>AI just made the old definition of done worthless<br>How to redefine done on your team<br>Frequently asked questions

QUICK ANSWER<br>The standard definition of done says work is finished when the code meets your team’s quality bar and ships. That definition is wrong, or at least dangerously incomplete. Done isn’t when the code ships. It’s when the customer’s problem is actually solved and you’ve confirmed it. And now that AI writes much of the code, the finish line has moved: the real work is deciding what to build and proving it mattered.

Ask a Scrum team what “done” means and you’ll get a clean answer. The Scrum Guide calls the definition of done “a formal description of the state of the Increment when it meets the quality measures required for the product.” Reviewed, tested, merged, deployable. Check the boxes and you’re done.

I’ve shipped software for more than 20 years, and I think that definition is quietly wrecking products.

Done isn’t when the code ships. It’s when the customer sees value.

The standard definition of done draws the finish line at the exact moment the engineer stops being useful and the customer still has nothing. Everything that determines whether the work mattered happens on the other side of that line, and the way most teams define “done” tells everyone to walk away right before it.

What the definition of done actually says today

To be fair to the idea, a definition of done does real work. It’s a shared checklist a team agrees on so that “done” means the same thing to everyone, instead of one engineer’s “done” being another’s “barely started.”

A typical definition of done looks like this:

Code is written and peer reviewed<br>Unit and integration tests pass<br>The feature meets its acceptance criteria<br>Documentation is updated<br>It’s merged and deployed to production

That’s useful. A team with no shared definition of done ships inconsistent junk, and people waste half their week arguing about whether a ticket is finished. I’m not against having one.

People mix up the definition of done with acceptance criteria, so it’s worth being precise. They are not the same thing.

Definition of doneAcceptance criteriaApplies to every work item on the teamSpecific to one story or featureQuality bar: tested, reviewed, deployableBehavior: does this story do what was askedSet once by the team, rarely changesWritten fresh for each story“Is it built to our standard?”“Did we build the right thing?”

Atlassian and most agile coaches draw the same distinction. Acceptance criteria tell you the story did what the ticket said. The definition of done tells you the increment is built to standard.

Here’s the problem. Both of them stop at the same place.

Both of them treat “done” as a property of the code. Neither one asks the only question that actually matters.

“Code shipped” is the wrong finish line

Did it work? That’s the question the standard definition never forces anyone to ask. Did the customer’s problem actually go away, and did anyone check?

For most teams, the honest answer is no, because the process gives them no reason to. The sprint ends, the ticket moves to Done, the next sprint starts, and there is no time built in to see whether the thing you shipped helped a single human being.

So you get the result the whole industry quietly lives with. Pendo studied feature usage across hundreds of products and found that 80% of features are rarely or never used. Most of what your team marks “done” is code that no customer ever touches.

Think about what that means. The majority of the work an engineering org ships, work that passed code review, passed tests, met its acceptance criteria, and was correctly marked done, delivered nothing. By the standard definition of done, all of it succeeded.

That’s not a quality problem. Your tests passed. That’s a definition problem.

When you ship without follow-through, you don’t just waste the effort. You accumulate product debt. Every unused feature is more code to maintain, more surface area for bugs, more weight the product carries forever. You can carry that the same way you carry technical debt, except it’s worse, because technical debt at least supports something a customer uses.

I lived this at VinSolutions, the auto-dealer software company I co-founded and later sold. We built features for car dealers that we were proud of and that, when I actually looked at the usage data, dealers never opened. We had shipped them. We had marked them done. The dealer’s problem was sitting right there, untouched, because nobody on the team owned the gap between “we deployed it” and “it changed something for the customer.” The definition of done told us to stop the moment the code went out.

That gap is where products...