Introduction
Having written a Definition of Done, a team almost always reaches for the mirror image: a checklist an item must satisfy before it can enter a sprint. Estimated. Acceptance criteria written. No blocking dependencies. Designs attached.
It looks obviously sensible, and it is the one common agile practice that experienced practitioners argue against on principle — describing it as either temporary training wheels for a new team or an outright anti-pattern.
Both positions are defensible, which is why this is worth thinking about rather than adopting. The question is not whether a Definition of Ready is good; it is what happens in your team when an item fails it.
What one usually contains
A typical Definition of Ready:
- The story has acceptance criteria.
- It is small enough to finish within the sprint.
- It has no unresolved external dependencies.
- The team has estimated it.
- Designs, content, or data the work needs are attached.
- The value or the reason is clear.
Nothing on that list is objectionable. Every item describes something genuinely useful for a story to have, and a story missing all six is going to have a bad sprint.
The case for it
The honest version of the argument is about a specific failure it prevents.
Work arrives half-formed, gets pulled into a sprint on optimism, and then spends four days waiting: for a decision nobody has made, an asset nobody has produced, a dependency nobody has raised. The sprint under-delivers, and the retrospective concludes that the estimates were wrong, which they were not.
A Definition of Ready gives the team a way to say "not yet" with a reason, and gives the product owner an early warning that refinement has fallen behind. For a team that has not yet developed the instinct to ask those questions unprompted, it is a genuinely useful prosthetic. It teaches what to ask.
The case against it
The criticism is not that the items are wrong. It is about what a checklist does to a relationship.
It turns refinement into a gate. Backlog refinement is meant to be a continuous activity — a bit of conversation, ordering, and splitting whenever the team learns something. A Definition of Ready encourages the opposite: a scheduled hour in which items are processed against a list until they are stamped, which is how a refinement session becomes a meeting people rush rather than think in.
It converts collaboration into a hand-off. This is the sharp end. The product owner prepares items; the team accepts or rejects them. That is a supplier-and-customer relationship, and a story is not a deliverable one side hands the other. The practices that produce good criteria — the three amigos conversation, a tester asking what happens when the service is down — work because both sides are writing, not because one side is checking.
It optimises for local completeness over flow. An item that fails one criterion is held back entirely, including the 90% that was ready to start. Sometimes that is right. Often the useful move is to start the part that is clear and resolve the rest in flight.
It becomes a place to hide. Once a rejection mechanism exists, it gets used for things it was not built for — disagreement about priority, discomfort with ambiguity, a sprint people would rather not fill. The checklist gives that a procedural voice, which makes it harder to discuss than it would have been as an opinion.
It is not part of Scrum. The Definition of Done is in the Scrum Guide, with teeth: work that does not meet it cannot be released or shown at Sprint Review. The Definition of Ready is not there. That is not an argument that it is forbidden — teams add practices constantly — but it is worth knowing that the symmetry the name implies does not exist in the framework.
The diagnostic
You do not need to settle the general argument. You need to know which version your team has, and there is one question that tells you.
When an item fails the Definition of Ready, what happens next?
- Someone starts a conversation about the gap, usually that day. The checklist is working. It is a prompt.
- The item goes back to the product owner's queue and waits for the next refinement session. The checklist has become a gate, and it is now costing you a sprint of latency per unanswered question.
The second pattern has a tell: a backlog where items bounce between "ready for refinement" and "needs more detail" more than once. That is not a quality process; it is a queue with extra steps.
If you keep one, keep it harmless
- Make it short. Three or four items. A long one is a document nobody reads and everybody cites.
- Make it the team's, not the product owner's homework assignment. If only one person can satisfy it, it is a hand-off.
- Allow starting anyway, explicitly, with a named person owning the open question. Most gaps are better resolved in flight than in a queue.
- Revisit it when it stops catching anything. A Definition of Ready that has not blocked an item in three months has taught what it was going to teach, and can be retired without ceremony.
- Never use it to reject priority. Priority is the product owner's call. If the disagreement is about order, have that argument in the open.
What to do instead
The problems a Definition of Ready is reaching for have more direct solutions:
For criteria that cannot be checked, fix the criteria. That is a writing problem with a known shape — observable outcomes, no vague words, a number on every limit — and it can be graded: paste a story into the acceptance criteria grader and see what a tester would have to ask. This is the single highest-value substitution, because "has acceptance criteria" is the Definition of Ready item most often satisfied by criteria that say nothing.
For stories too big to finish, practise slicing rather than measuring. The test is not size but whether half of it could ship and still be worth something.
For missing dependencies, make them visible on the board instead of checking for them at the door. A dependency discovered at refinement is a dependency discovered too late anyway.
For unclear value, that is the "so that" clause in the story, and it is the product owner's to write.
Conclusion
A Definition of Ready is a useful teaching tool and a poor permanent institution. It works while it is prompting questions a team has not yet learned to ask, and it turns against you the moment it becomes the mechanism by which one part of the team declines another part's work.
Watch what happens when an item fails it. If the answer is a conversation, keep it. If the answer is a queue, the checklist is no longer helping — and the underlying problem is almost always criteria that nobody could have checked in the first place, which is a fixable writing problem rather than a process one.
For the checklist that genuinely does need teeth, see acceptance criteria vs definition of done.