Definition of Done vs Definition of Ready: What's the Difference?
Both definitions are quality checklists, but they guard opposite ends of the workflow. The Definition of Ready asks: is this backlog item prepared enough to start? The Definition of Done asks: is this work truly finished? Only one of them is an official part of Scrum — and mixing up their purpose causes real problems.
Definition of Done: Scrum's quality commitment
The Definition of Done (DoD) is a formal commitment attached to the Increment in the Scrum Guide. It describes the state every completed item must reach before it can be considered part of the Increment — and it applies to everyone: if work doesn't meet the DoD, it doesn't ship, it returns to the Product Backlog.
A typical software DoD:
- Code reviewed and merged to main
- Unit and integration tests written and passing
- Acceptance criteria verified
- No new critical or high defects
- Documentation and monitoring updated
- Deployed to (at least) a production-like environment
The DoD's power is honesty: it's the difference between "done" and "done except testing, review and deployment" — the gap where late-project chaos lives. A weak DoD silently accumulates undone work that erupts at release time.
Definition of Ready: a useful practice, not a rule
The Definition of Ready (DoR) is a team convention — it appears nowhere in the Scrum Guide. It lists what a Product Backlog item should have before the team pulls it into a Sprint, for example:
- Clear user-facing description and acceptance criteria
- Dependencies identified
- Sized by the Developers
- Small enough to finish within a Sprint
Used well, a DoR is a refinement conversation prompt that prevents half-understood work from ambushing a Sprint. Used badly, it becomes a stage gate: items bounce back with "not ready" stamps, refinement turns bureaucratic, and collaboration is replaced by hand-offs. The Scrum Guide's own guidance — items that can be Done within one Sprint are "deemed ready" — is deliberately loose. Treat Ready as a guideline, Done as law.
Key differences at a glance
| Definition of Ready | Definition of Done | |
|---|---|---|
| Applies to | Product Backlog items entering a Sprint | Every item in the Increment |
| Status in Scrum | Optional team practice | Formal commitment |
| Guards against | Starting vague work | Shipping unfinished work |
| Risk when misused | Becomes a bureaucratic gate | Becomes fiction ("done*") |
Making both work together
Strong teams keep the DoR light (three to five bullet points) and the DoD demanding — then strengthen the DoD over time as capability grows (adding automated regression, performance checks, security scans). Both checklists are living agreements, revisited in Retrospectives, not laminated posters.
Crafting and enforcing these agreements is bread-and-butter Scrum Master and Product Owner work — covered practically in CSM training and PSPO training. For the full Scrum Master syllabus, see the CSM certification guide.
Frequently asked questions
Who owns the Definition of Done?
The Scrum Team creates it — unless an organisational standard exists, in which case the team must meet it as a minimum and may strengthen it.
Can we have different DoDs for different item types?
Better to have one DoD with conditional lines ("if user-facing, UX review") than parallel definitions that invite arguments about which applies.
Is a Definition of Ready against Scrum?
No — it's simply not required. It's a helpful refinement aid as long as it never blocks collaboration or becomes an excuse to refuse work.