Definition of Done

---

Origins

Definition of Done is one of the few elements the Scrum Guide¹ defines explicitly. The DoD is a formal description of the state of the Increment when it meets the quality measures required for the product. The team commits to nothing less than DoD when delivering each Increment.

The practice predates Scrum — quality checklists have existed in software for decades — but Scrum elevated DoD to a first-class artifact that the whole team owns. The DoD is the team's promise to itself and to stakeholders about what "done" actually means.

What a DoD Contains

Typical Definition of Done criteria:

• Code is written and reviewed: at least one other developer has reviewed.
• Tests are written and passing: unit tests, integration tests where appropriate.
• Code is merged to mainline: trunk or main, not languishing on a branch.
• Acceptance criteria are met: as stated in the story.
• Documentation is updated: code comments, runbooks, user-facing docs as relevant.
• Deployed to an environment: at minimum staging; ideally production for teams doing continuous deployment.
• Verified by the Product Owner: someone who can speak for the business agrees it works.
• No new critical defects introduced: regression tests pass.
• Performance and security checks pass: automated where possible.
• Observability in place: logging, metrics, alerts for new code paths.

The list is team-specific. A backend service team's DoD differs from a UI-heavy product team's. The discipline is making it explicit and complete enough that the team agrees an item meeting all criteria is genuinely shippable.

Why the DoD Is the Most Leveraged Agreement

Several reasons:

• It converts hidden disagreement to explicit shared standard: developers, PMs, testers, and ops people often have different mental models of "done." The DoD makes the model explicit.
• It prevents debt accumulation: items that ship without meeting DoD turn into debt — "we'll add tests later," "we'll write docs later." DoD prevents the deferral.
• It enables real Sprint Reviews: a sprint where items meet DoD produces a real demo of working software; a sprint where items "are done except for tests" produces a status report.
• It scales: the DoD travels with the team. New members learn it; the team can hold itself to it without management oversight.
• It is the floor, not the goal: DoD is the minimum acceptable; great work exceeds it. But the floor matters — without it, "done" means whatever each person thinks at the moment.

Building a Definition of Done

1. Identify what "done" has meant variably

Where has the team disagreed about whether something was done? What rework happened because someone considered an item finished and someone else didn't? These conflicts are the seed of the DoD.

2. Draft initial criteria

The team writes down what they think should be in. Start broad; refine later.

3. Test against recent work

Walk through a few recent stories. Does the draft DoD capture what the team would have wanted "done" to mean? Add what's missing; remove what's overhead.

4. Make criteria observable

Each item should be checkable. "Code is well-tested" is subjective; "code has tests that exercise the happy path and the documented edge cases" is observable.

5. Commit and visualize

The DoD goes on the wall, in the team channel, in the wiki. Visible enough that it's referenced in conversations, not buried in a document nobody opens.

6. Update when reality shifts

The team grows, the technology changes, customer expectations rise. The DoD should reflect the team's current understanding of quality, not the snapshot from project kickoff.

The Multiple-Level DoD

Mature teams often have layered DoDs:

• Story DoD: what makes a single story done.
• Sprint DoD: what makes a sprint Increment done (integration, regression, possibly deploy to staging).
• Release DoD: what makes a release done (production deploy, customer notification, support readiness).

Each layer adds criteria that don't fit at lower granularity. A story doesn't need a customer-notification email; a release does.

DoD vs. Done-Done

Some teams distinguish between Definition of Done (what the team commits to per story) and Done-Done (what it actually takes to ship to customers). The distinction matters when the team's Sprint Increment isn't actually deployed to customers each sprint.

Common Pitfalls

• DoD that the team doesn't actually meet: the document says "tests pass" but the team regularly ships without tests. The DoD becomes fiction.
• Generic DoD from a book: copied without reflecting the team's actual work. Doesn't fit; gets ignored.
• Vague criteria: "well-tested" or "high quality" lets each person interpret differently. Push for observable.
• DoD as decoration: posted on the wall, never referenced in conversations. Loses its working-artifact status.
• Sprint DoD treated as release DoD: items "done" per Sprint DoD aren't actually shippable. The gap creates surprise at release time.
• Static DoD: written at project kickoff, never updated. The team's understanding of quality has moved; the DoD hasn't.

Coaching Tips

Build from Disagreement

Where did the team disagree about whether something was done? Those moments are the DoD's source material.

Make Criteria Observable

"Quality code" is unverifiable. "Code reviewed by at least one teammate" is. Push for criteria the team can actually check.

Hold the Line Under Pressure

The day the team ships something that doesn't meet DoD is the day the DoD starts to die. Coach against the exception.

Layer DoDs as Needed

Story DoD, Sprint DoD, Release DoD — different scopes have different bars. Don't conflate.

Visualize Aggressively

DoD on the wall, in the team channel, in PR templates. Anywhere it's likely to be referenced during work.

Update Quarterly

The team that learns more about quality should reflect that learning in the DoD. Static DoDs go stale.

Summary

Definition of Done is the cheapest, highest-leverage agreement a team can make. The cost is an hour of writing and the discipline to honor it; the benefits compound across every story the team ever ships. Teams without explicit DoD pay in rework, surprise debt, ambiguous reviews, and the slow erosion of what "done" means within the team.

The discipline lives in actually meeting the DoD — not in writing it. A team that writes a beautiful DoD and routinely ships items that don't meet it has the worst of both worlds: the appearance of quality without the substance. The honest practice is writing a DoD the team actually intends to meet, holding the line under pressure, and updating it deliberately as the team's understanding of quality grows.

Back to Agile Delivery