Skip to content
Foundationsboth

Definition of Done

Agreeing what "done" means before you start, so "done" doesn't mean "demo-ready" to you and "shipped" to engineering.

The short version

A Definition of Done (DoD) is a shared, explicit checklist of what must be true for work to count as complete, agreed before the work starts. Without it, "done" is a word everyone interprets differently: the PM means "the feature works in a demo," engineering means "code is merged," and the customer means "I can actually use it reliably." A good DoD turns that ambiguity into a contract.

Why it matters

"Is it done?" is the most overloaded question in product. The cost of leaving it undefined shows up late and expensive: a feature gets called done, the team moves on, and then the bugs, the missing analytics, the un-written docs, and the accessibility gaps surface in production, as new work, with the context already gone.

A Definition of Done is the cheap fix: a short, standing checklist the whole team agrees on once, then applies to every item. It is not the acceptance criteria for one feature (that is the spec's job), it is the universal bar that every feature must clear regardless of what it is.

What belongs in a DoD

01
Functional. Meets the acceptance criteria in the spec; the core user journey works end-to-end.
02
Quality. Code reviewed and merged; tests written and passing; no known Sev-2 bugs.
03
Instrumented. The success metric is actually being measured, you can tell, post-launch, whether it worked.
04
Resilient. Edge cases handled; there is a rollback or kill-switch; on-call knows it exists.
05
Accessible & compliant. Meets accessibility, localization, and any legal/privacy requirements, not a follow-up.
06
Documented. Enough docs/runbook that someone who is not you can support it.

Common mistakes

Confusing DoD with acceptance criteria, DoD is the universal bar for all work; acceptance criteria are specific to one feature.

Defining "done" as "code complete", that ignores measurement, docs, accessibility, and supportability, which become surprise work later.

Writing a DoD nobody agreed to, if engineering and QA did not sign off, it is your wish list, not a shared contract.

Never revisiting it, a DoD should tighten as the product matures (a pre-launch prototype and a scaled product deserve different bars).

In a startup

Keep it short, a 4-line DoD the team actually honors beats a 20-line one they ignore. Early on, "works, measured, and won't embarrass us" is often enough.

In an enterprise

The DoD is where compliance, localization, accessibility, and security reviews get baked in as non-negotiable steps, so they stop being the thing that blocks launch at the last minute.

Quick check

0/2

Optional, find the right answer for each to complete the concept. Keep trying; nothing is gated.

1. How does a Definition of Done differ from acceptance criteria?

2. Why is defining "done" as "code complete" a mistake?