Key takeaways
  • Definition of Ready says you can start it; Definition of Done says you can ship it.
  • Two short lists prevent half the arguments in product.
  • Done becomes theatre if it isn't enforced. Tighten the gates for regulated and payment work.

Two thirds of the friction inside a delivery team (refinement that overruns, sprints that go off-rails halfway through, stories that ship and then come back marked "not quite done") comes from the same root cause. The team has never written down what ready means, and never written down what done means. So every story is a small negotiation. Every acceptance ceremony is a fresh argument. And every retro produces the same action item: "we should agree on quality." The agreement never appears, because nobody owns writing it down.

Definition of Ready and Definition of Done are the two artefacts that close that gap. They are short: fifteen lines between them, easily. They are visible, and they are team agreements, not industry standards. There is no canonical DoR or DoD that applies to every team. There is the one you wrote together, posted in the channel, and pin to the top of refinement. The act of writing them is most of the value. The act of enforcing them is the rest.

What each one is, in one sentence.

Definition of Ready is the checklist a story passes before it can enter a sprint. It is the gate between Refined and In-flight on the backlog (see N°34 · The Backlog). If a story does not meet DoR, it does not get pulled in, no matter how loud the stakeholder asking. The DoR exists to protect the sprint from chaos that the team cannot finish.

Definition of Done is the checklist a story passes before it can be marked complete and the team can move on. It is the gate between In-flight and Done. If the story does not meet DoD, it is not finished, even if the engineer is keen to close the ticket and the PM is keen to update the burndown. The DoD exists to protect production, and the next sprint, from work that looks finished but isn't.

Diagram · The two checklists, side by side
Definition of Ready and Definition of Done — two checklists at the start and end of the sprint Two parallel checklist cards. The left card, Definition of Ready, lists six criteria a story must meet before it enters a sprint — clear acceptance criteria, no unresolved dependencies, designs in place if needed, T-shirt sized, owner identified, persona and outcome named. Each item carries a marigold tick mark. The right card, Definition of Done, lists seven criteria a story must meet before it can be marked complete — code reviewed, unit tests passing, integration tests passing, deployed to staging, AC verified by PO, demo-ready, observability and logging in place. Each item carries a marigold tick mark. Between the two cards a wide arrow shows the work itself happening in the middle, with day-counter ticks marking the duration of the sprint. Below the arrow a marigold callout strip reads: These are team agreements, not industry standards. Write your own. CHECKLIST 01 Definition of Ready you may start this Persona & outcome named Acceptance criteria sharp Dependencies unblocked Designs in place if needed T-shirt sized Owner identified GATE — REFINED → IN-FLIGHT CHECKLIST 02 Definition of Done you may ship this Code reviewed Unit tests passing Integration tests green Deployed to staging AC verified by PO Demo-ready Observability in place GATE — IN-FLIGHT → DONE These are team agreements, not industry standards. Write your own.
Two short checklists, one at each end of the sprint. The middle is where the work actually happens. Write them with the team. Copying someone else's DoR/DoD verbatim is half the reason most of them get ignored.

A sample Definition of Ready.

Most working teams converge on roughly six items. Here is a defensible starting point you can adapt:

  • Persona and outcome named. The story explicitly says who it serves and what changes for them. If the story is "improve the API" with no user named, it is not ready.
  • Acceptance criteria sharp. Objective, checkable, no weasel words. "The page loads in under 2 seconds", not "the page loads quickly". See N°33 · Acceptance Criteria for the long version.
  • Dependencies identified and unblocked. If the story needs an API another team owns, that team has committed to delivery before this sprint starts. If it needs legal sign-off, that has happened. Identified-but-not-unblocked doesn't count.
  • Designs in place if needed. Not every story needs a Figma. But if the story has a UI surface, the design exists and engineering has reviewed it.
  • Estimated. The team has agreed a rough size: T-shirt, points, or hours, whichever your team uses. A story that nobody has sized is a story nobody has actually thought about.
  • Owner identified. One name on the story: the person who'll pick it up first. Stories that say "the team" or are unassigned end up assigned to nobody.

That's it. You can add more (many teams add a regulatory or accessibility check), but every item you add raises the bar on what enters the sprint, and that's a cost. The DoR should be the minimum bar, not the wish list.

A sample Definition of Done.

Done is longer than Ready, because there is more to verify after the work than before it. A working DoD typically lands on seven or eight items:

  • Code reviewed. At least one other engineer has approved the PR.
  • Unit tests written and passing. Coverage at the team's agreed threshold for the touched code.
  • Integration tests passing. End-to-end suite green on the build.
  • Deployed to staging. The change is actually running somewhere a human can poke at it, not just merged.
  • Acceptance criteria verified by the PO. Not by the engineer who wrote the story. By the PO who'll defend it. See N°28 · The PO Piece.
  • Demo-ready. Someone can walk a stakeholder through it without needing to apologise for what's broken.
  • Observability in place. Logs, metrics or events exist for the new behaviour. If it breaks in production, you'll know.
  • Documentation updated. Whatever the team's level of docs (runbook, user help, internal wiki), the relevant page has been touched.

For regulated work — payments, healthcare, anything touching PII — the DoD tightens further. Add explicit security review, a data-handling check, a compliance sign-off step. The right DoD for a fintech team writing payments code is not the right DoD for a marketing site team. Different work, different gates. Don't apologise for that.

If your team can't say what 'done' means, you don't have a team. You have parallel individuals.

The trap: DoD as theatre.

The most common failure mode isn't the absence of a DoD. It's a DoD that exists on a wiki page nobody reads and nobody enforces. Stories close. The burndown looks healthy. Six weeks later something breaks in production and the root cause is a story marked Done with no observability, no integration tests, no real verification: just an engineer who ticked the box because everyone was tired and the sprint was ending.

The fix is mechanical. Put the DoD into the pull request template. Every PR opens with the eight checkboxes pre-populated. Reviewers won't approve until they're ticked, because they have to actively un-tick them to merge. Wire the DoD into the column-move automation in your tool of choice, so moving a card to Done requires the AC-verified checkbox to be true. Make the next ceremony (sprint review, demo, retro) a place where stories that don't meet DoD are visibly called out, not glossed over.

None of that is cultural. It is process plumbing. Cultural enforcement ("we just need to be more disciplined") fails every time, because every team has weeks when discipline runs out. Mechanical enforcement works on a bad week, which is the only week that matters.

Why DoR matters more than people think.

Most teams put far more energy into Definition of Done than Definition of Ready. That's the wrong way round. A weak DoD costs you a hotfix two weeks after release. A weak DoR costs you the entire sprint.

The pattern goes: an under-specified story enters the sprint because somebody important asked for it. The engineer starts work, runs into the first ambiguity on day two, blocks on getting an answer. The PO is in interviews; the design is half-done; the dependency on another team's API was never confirmed. The story sits at 60% complete for the rest of the sprint. Other stories get pulled in to fill the gap, but those weren't refined either. By the end of the sprint, half the work is half-done, and the team's velocity for the next sprint is also wrecked because the carry-over fills it.

All of that is prevented by a DoR that says: this story cannot enter the sprint until the design exists, the dependency is unblocked, and the AC is sharp. Boring sentence. Saves a sprint. Worth more than any retro improvement you'll ever make.

Tighter gates for regulated and payment work.

If your product handles money, regulated personal data, or anything where a mistake has legal or financial consequences, both checklists tighten. The DoR adds: security review scheduled, data classification confirmed, error states explicitly defined. The DoD adds: penetration test passing (if applicable), audit log emitted, rollback plan documented, GDPR/data-handling sign-off recorded, on-call team briefed.

That looks heavy, and it is. The point is that the cost of getting it wrong is paid in regulatory fines, customer trust, and engineering hours spent in incident review. The cost of getting it right is half an hour at the start and end of the sprint. Cheap insurance.

Where this lands at Product Pieces.

When we run the Backlog Set Piece with a team, writing the DoR and DoD is one of the four outputs. We do it in the room, with engineering, PO, and design present — not as a wiki dump from a template, but as a fresh conversation about what this specific team will commit to. The act of writing them together is most of the value. The team that wrote them is the team that will enforce them.

If your team has two anti-patterns from N°22 (mausoleum backlog, under-specified stories entering sprints, work coming back marked "not quite done"), the missing artefact isn't another tool. It's these two short lists, agreed and enforced.

Next issue: N°07 is Story Mapping. The flatness problem, solved.