Definition of Ready: Should Your Team Use It?
The Definition of Ready (DoR) is a set of criteria that a Product Backlog Item (PBI) must satisfy before it is eligible to be pulled into a Sprint. It is the pre-Sprint counterpart to the Definition of Done — which defines when a backlog item can be considered complete at the end of a Sprint. A typical Definition of Ready might require that a story: has a clear, actionable description; has acceptance criteria that the team understands; has been estimated by the Development Team; has no unresolved dependencies that would block completion within the Sprint; and is small enough to be completed within a single Sprint. On the surface, this looks reasonable — even obviously good practice. But the debate about whether teams should formalise a DoR is worth having carefully.
The argument for a Definition of Ready
The strongest case for the DoR is efficiency. Sprint Planning is time-boxed and should result in a Sprint Backlog that the team is confident it can deliver. When poorly-prepared stories enter Sprint Planning — stories without clear acceptance criteria, stories that depend on decisions not yet made, stories that are too large to finish in a single Sprint — the Sprint Planning session degenerates into an extended clarification meeting. The team loses confidence in the Sprint Goal before the Sprint has even started. The DoR prevents this by ensuring that only work that is genuinely ready for implementation enters the Sprint. For teams in organisations where requirements clarification is historically slow or where dependencies are chronic, a DoR can provide useful forcing function discipline on the Product Owner and stakeholders.
The argument against
The case against the DoR is more subtle but equally valid. The first objection is that it creates a gate. When readiness criteria become a formal checklist, the team can refuse to take work into a Sprint on the grounds that the story is "not ready" — even when the team has enough information to start and can reasonably resolve remaining questions early in the Sprint. This turns a quality standard into a blocking mechanism. It can slow delivery and penalise a Product Owner who is working hard to prepare stories but whose stakeholders are difficult to pin down.
The second objection is philosophical. Scrum is an empirical framework — it is designed to enable teams to learn from doing and to adapt based on experience. The empirical approach tolerates some upfront uncertainty as the cost of agility. A rigid DoR pushes the team toward a planning-forward mentality: everything must be known before work begins. This is closer to the waterfall mindset than the agile one. Ken Schwaber and Jeff Sutherland, the authors of the Scrum Guide, notably do not include the Definition of Ready in the Guide. It is a community practice, not a Scrum prescription. Scrum purists argue that if a team needs a formal gate to keep unprepared work out of the Sprint, the problem is the quality of backlog refinement — not the absence of a readiness checklist.
A practical middle ground
Use informal readiness criteria without a formal gate. The team and Product Owner can develop shared expectations about what a well-prepared story looks like without formalising those expectations as a gate. During backlog refinement, the team signals when a story is not clear enough to estimate reliably. During Sprint Planning, the Product Owner is expected to have the top backlog items ready. But there is no formal checklist that can be invoked to refuse work that is close enough to start. This captures most of the benefit of a DoR without the rigidity.
Reserve the DoR for specific problem contexts. A formal DoR is most defensible when a team has a demonstrated, recurring problem with poorly-prepared stories entering Sprints and disrupting delivery. It is a corrective mechanism, not a default practice. Teams that do not have this problem do not need the overhead of maintaining and enforcing a formal checklist.
Treat it as a temporary scaffold, not a permanent fixture. If a team introduces a formal DoR to address a specific breakdown, it should also set a trigger for re-evaluating whether the DoR is still needed once the underlying problem has been resolved. Scaffolding that remains after the building is standing becomes an obstacle rather than a support.
The Definition of Ready is a tool, not a rule. Like most Scrum practices, its value depends entirely on the context in which it is applied and the discipline with which it is maintained. Teams that use it to create bureaucratic cover for refusing to start difficult work will find that it slows them down more than it helps. Teams that use it to establish shared expectations about the minimum information needed to deliver reliably will find it genuinely useful. The deciding question is not "should we have a DoR?" but "do we have a recurring problem that a DoR would solve, and is the overhead of maintaining it worth the benefit?"
Getting Scrum practices right — including the decision about which practices to adopt — is as much a team coaching question as a methodology question. XNM's program and project delivery advisory works with teams and organisations to build agile delivery capability that reflects the actual context of the work, not a checklist abstracted from it.