Read this before you copy it.
The Definition of Ready is not in the Scrum Guide, and it is genuinely contested. Critics — including well-known Scrum trainers — argue that a formal DoR becomes a stage gate. A mini-waterfall, where work has to be “fully specified” before developers are allowed to touch it, which undermines the collaboration that makes Scrum work in the first place.
That criticism is fair. Know it before you propose one.
The position taken in the book: a lightweight DoR helps a new team and gets in the way of a mature one. Training wheels.
The failure mode is treating it as a contract that lets developers refuse work, rather than as a prompt to have a conversation.
The standard
Four lines. Not fourteen. If your list needs a scroll bar, you have built a stage gate.
- An item is Ready when
- The story states a user, an action, and a benefit
- Acceptance criteria are written and approved by the Product Owner
- The Developers have broken it into tasks and produced an estimate
- No known blocking dependency is unresolved
What happened the first time it was tested
US1.1 was checked against this list before Sprint 1.
| Line | ||
|---|---|---|
| 1 | States a user, an action, a benefit | Met |
| 2 | Criteria written and approved | Met |
| 3 | Broken into tasks, estimated | Met |
| 4 | No unresolved blocking dependency | Not met |
Line four failed. The twelfth acceptance criterion on that story redirected to a “Verify Your Email” screen that no story in the backlog covered. An unresolved dependency, in plain sight, spotted during refinement.
By the team's own Definition of Ready, US1.1 was not Ready.
They took it into Sprint 1 anyway.
That decision cost them at the Sprint 1 Review, and the story of what happened is in chapter 1, free to read.
Anybody can write a Definition of Ready in ten minutes. The interesting part is what a team does the first time something fails it and everybody in the room wants to proceed regardless.
The backlog it was checked against
Worth looking at the shape of this, not just the contents.
| Item | Estimate | Ready? |
|---|---|---|
| US1.1 | 26–40 h | Conditional — dependency open |
| US1.2 | 18–26 h | Yes |
| US1.3 | 14–22 h | Yes |
| US1.4 | not refined | No |
| E02 stories | not refined | No |
The top is detailed. The bottom is a single line. That is the rolling wave, and it is intentional — a backlog where everything is equally refined is a backlog where somebody wasted a great deal of time specifying work that will change before anyone builds it.
Why the estimates are ranges.
Because a single number hides uncertainty. “Five to eight hours” tells the truth in a way “6.5” never can. When a developer hands you a single number, they have either hidden their uncertainty or been trained out of showing it.
These are hours rather than story points because this was a brand-new team. Points are relative — they mean something only once you have history to compare against, so a new team's first point estimate is a number with nothing behind it. It feels rigorous and it isn't.
Hours have their own drawback: they invite managers to treat them as commitments and start calculating utilisation. The range is what protects you.
When to retire it
A Definition of Ready is training wheels. It exists to give a new team a shared vocabulary for “we can't start this yet” without it becoming a personal objection.
Signs it has outlived its usefulness:
- Refinement conversations end with someone citing the list rather than asking a question
- Items sit unrefined because nobody wants to be the one who brings something “not Ready”
- The team has enough history to size work by comparison instead of by task breakdown
At that point, delete it. Leaving it up after a team has matured teaches them that permission comes from a checklist.
The companion standard
The Definition of Ready is a gate before work starts, and optional. The Definition of Done is what the team is held to afterwards, and it is a Scrum commitment rather than a practice choice. If you only adopt one, adopt that one.