Two quality gates that bracket every sprint. Ready stops half-baked work entering; Done stops half-finished work leaving. Together they make commitments trustworthy.
▸ Try the interactive toolThe Definition of Ready (DoR) and the Definition of Done (DoD) are two explicit quality gates that bracket every sprint. The DoR ensures a story is fully prepared before it's allowed into a sprint. The DoD ensures a story is genuinely complete before it's allowed out. Together they protect the team from committing to unclear work and from shipping unfinished work.
Both are shared, explicit checklists the team agrees in advance. The DoR might require a story to have clear acceptance criteria, a known design, and no blocking dependencies before it enters a sprint. The DoD might require code reviewed, tested, documented, and deployable before a story counts as done. The power is that they make two fuzzy, contested words — ‘ready’ and ‘done’ — into objective, agreed standards that don't shift under pressure.
Definition of Ready — the checklist a story must pass to enter a sprint (clear criteria, design known, no blockers).
Definition of Done — the checklist a story must pass to leave as complete (reviewed, tested, documented, deployable).
Without these gates, ‘ready’ and ‘done’ mean whatever is convenient in the moment — so unclear work enters sprints and half-finished work gets called complete.
| The shortcut | What it costs | What it gives you instead |
|---|---|---|
| No Definition of Ready | Unclear, under-specified stories enter the sprint and stall mid-way. | The DoR stops half-baked work from being committed to. |
| No Definition of Done | ‘Done’ means ‘code written’ to one person, ‘shipped’ to another. | A shared DoD makes completion objective and consistent. |
| Hidden incompleteness | Stories marked done that aren't tested or documented resurface as bugs. | The DoD catches the un-done work before it's called done. |
| Pressure-driven shortcuts | Under deadline, ‘done’ quietly loosens to hit the sprint. | An explicit, agreed DoD resists the pressure to cut corners. |
Decide what a story must have before it can enter a sprint — clear acceptance criteria, agreed design, sized, no blocking dependencies. Agree it together so it's owned, not imposed.
Decide what ‘done’ truly means — reviewed, tested, documented, deployable, acceptance criteria met. The same checklist for every story makes completion consistent.
In planning, only commit to stories that meet the DoR. Pulling in an unready story is borrowing a problem you'll pay for mid-sprint.
A story is only done when it passes the DoD — no exceptions for ‘basically done.’ This is what makes the increment trustworthy and velocity meaningful.
The gates earn their value precisely when a deadline tempts the team to loosen them. Defending the DoD when it's inconvenient is the whole point.
Under deadline pressure, a team started marking stories ‘done’ when the code was written but not yet tested or documented — the Definition of Done had quietly loosened to hit the sprint. Velocity looked great. Then the untested work came back as a wave of bugs the following sprint, costing far more than the time ‘saved.’
The Definition of Done existed precisely to prevent this, but only if it's held when it's inconvenient. Restoring the discipline — a story isn't done until it passes the full, agreed checklist — made velocity honest again and stopped the bug wave at its source. The deadline pressure was real; loosening ‘done’ just deferred and multiplied the cost.
The deliverable is two agreed, explicit checklists — DoR and DoD — applied consistently as the entry and exit gates of every sprint.
| Gate | Checks before… | Example items |
|---|---|---|
| Definition of Ready | A story enters the sprint | Clear criteria, design known, sized, no blockers |
| Definition of Done | A story leaves as complete | Reviewed, tested, documented, deployable |
‘Ready’ and ‘done’ are the two most quietly contested words in software delivery. The DoR and DoD turn them into objective, shared standards — which is what makes a sprint commitment and a velocity figure actually mean something.
The DoD in particular is where integrity is tested, because its value shows up precisely when honouring it is inconvenient. Under deadline pressure, ‘done’ is the easiest thing in the world to quietly redefine — code written becomes ‘done,’ testing and documentation become ‘later’ — and the sprint hits its number while accumulating invisible debt. That debt always returns, usually as bugs, usually more expensive than the corner that was cut. A Definition of Done only protects the team if it's treated as non-negotiable, especially when a deadline makes loosening it tempting. Holding the gate when it's hard is the entire point; holding it only when it's easy is the same as not having one.
The classic, costly mistake. Un-done work returns as bugs. Hold the DoD when it's inconvenient.
Pulling unready stories into a sprint borrows a problem you'll pay for mid-sprint.
Without a shared DoD, completion is subjective and quality drifts. Make it explicit.
The team must own the checklists, or they'll be ignored. Agree them together.
The DoD is the Increment artifact's commitment (Tool 05) — it's what makes ‘done’ trustworthy.
A story's acceptance criteria (Tool 15) are often part of both the DoR and the DoD.
An honest DoD is what keeps velocity (Tool 03) meaningful — loose ‘done’ inflates it falsely.
Holding the gates is part of the PM's in-sprint scope discipline (Tools 16, 17).
Write down what ‘done’ should mean for a story (reviewed? tested? documented? deployable?). Then recall the last deadline crunch — which of those got quietly dropped?
Consider what the dropped items cost later. Would holding the gate have been cheaper than the bugs or rework that followed?
If ‘done’ loosened under pressure and the cut work came back as bugs, you've seen exactly why the DoD has to be held when it's inconvenient — that's the only time it actually protects you.