Done-Done

Origins

The phrase done-done entered the agile vocabulary in the mid-2000s, popularized by Bill Wake, Mike Cohn, and a generation of Scrum coaches frustrated with what they kept hearing in standups: “It’s done — I just need to write the tests… and merge it… and deploy it… and check the logs.”¹ The word done, it turned out, was doing a lot of quiet shape-shifting.

Where Definition of Done codifies the bar for a single increment, done-done reaches further: it asks whether the work has actually arrived in production, whether anyone has used it, and whether the team has seen the effect. It is a cultural antidote to the optimism that creeps into every status report.

The Three Layers of Done

Most teams, when pressed, can articulate three concentric layers of completeness — and most of the disagreement in delivery comes from people standing on different layers while using the same word.

• Done. The developer believes the work is finished. Code compiles, the happy path works on their machine, the ticket can plausibly be moved to the next column.
• Done according to the DoD. The team’s explicit checklist is satisfied — tests pass, code is reviewed, documentation updated, acceptance criteria met. The increment is potentially shippable.
• Done-done. The change is in the hands of real users, the team has observed it behaving correctly in production, and the intended outcome — or its absence — has been measured.

The gap between the second and third layer is where most of an organization’s delivery drama lives. A team can hit every box on the DoD and still be months away from done-done if releases are batched, telemetry is thin, or no one is watching what happens after the deploy.

Why “Done” Keeps Slipping

Done slips because the incentives around it slip. Developers are rewarded for closing tickets, project managers for hitting sprint commitments, executives for shipping by quarter-end. None of those measures require the change to actually work in the world. Done-done corrects the focal length: the unit of value is not the merged PR, it is the customer who got the thing and is using it well.

Three failure modes recur:

• Inventory disguised as progress. Features pile up in pre-production environments, waiting for a release window that keeps moving.
• Telemetry blindness. The team ships, then turns its attention to the next sprint. No one notices that adoption is flat or that the error rate doubled.
• Outcome amnesia. The original reason for building the thing — the business hypothesis — gets lost between the brief and the release. By the time the feature is live, no one remembers what success would have looked like.

Done-Done in Practice

Operationalizing done-done usually means extending the team’s definition of done beyond the merge:

• Released, not merely deployed. Behind a flag is fine; behind a flag indefinitely is not. Done-done requires the change to be exposed to its intended audience.
• Observed in production. The team has watched the relevant dashboards, error rates, and key flows for at least one full usage cycle.
• Adopted. Some non-trivial portion of the target users has encountered the change. If adoption is zero, the team learns nothing.
• Evaluated against intent. The team has revisited the original hypothesis and recorded what happened — confirmed, refuted, or still unclear.

None of this requires elaborate ceremony. A weekly five-minute review of recently shipped items — did it land, who used it, what did we see — closes the loop more reliably than any tooling investment.

Done-Done vs. Definition of Awesome

Done-done sets the floor: the change has actually arrived and is behaving. The Definition of Awesome reaches for the ceiling — what would make this work delightful, not just acceptable. Healthy teams hold both, and resist the urge to collapse them. The bar to call something finished should not be the same bar you aspire to clear on your best days.

Coaching Tips

Name the layers explicitly.

When someone says “it’s done,” ask which kind. The pause that follows is usually instructive.

Add a post-release checklist.

Three boxes — released, observed, adopted — at the bottom of every story. Tickets don’t close until they’re all checked.

Hold a weekly “did it land?” review.

Five minutes, the whole team. Walk through what shipped, what the telemetry says, what surprised anyone.

Tie the story back to its hypothesis.

The original brief should be visible at close-out. If no one remembers why you built it, you can’t tell whether it worked.

Watch for flag debt.

Features hiding behind disabled flags are not done-done. Schedule the exposure or kill the work.

Celebrate landings, not merges.

What the team celebrates is what the team optimizes for. Move the applause downstream of the deploy.

Summary

Done-done is the quiet correction to a vocabulary that lets work feel finished long before it has done anything in the world. It asks the question that ticket-closing rituals tend to skip: did it land, and did it matter? Teams that practice done-done shrink the distance between code and consequence — and, over time, the distance between effort and outcome.

Back to Agile Delivery