Definition of Ready

---

Origins

Definition of Ready (DoR) emerged in Scrum and Agile practice as a counterpart to Definition of Done. Where Definition of Done answers "when is this finished?" Definition of Ready answers "when is this safe to start?" The pattern was popularized as teams encountered the same problem repeatedly: stories pulled into sprints that turned out to be too vague, too big, or missing critical information.

The concept has a complicated reputation. Many Agile coaches and Scrum.org consider DoR an anti-pattern when applied as a hard gate; others find it essential for protecting sprint focus. The right framing splits the difference: a DoR is a useful working agreement when applied as a guideline, harmful when applied as a stage-gate that blocks work.

What a Definition of Ready Includes

Typical DoR criteria for a user story:

• Clear acceptance criteria: the team knows what "done" looks like.
• Estimated: the team has a rough size (story points, T-shirt, or implicit sense).
• Sized appropriately: small enough to fit in a sprint, with room to spare.
• Dependencies identified: cross-team or external dependencies are known.
• Independent: can be worked without waiting on something else mid-sprint.
• Stakeholder available: someone can answer questions if they come up during work.
• Design ready (if needed): UX design or technical design has been done.
• Test approach known: how the team will validate the work.

The list varies by team. A backend service team's DoR looks different from a UX-heavy product team's. The discipline is making it explicit, not copying it from another team.

The Promise of DoR

A working DoR addresses real problems:

• Sprint capacity wasted on stories that turn out to be too vague to deliver.
• Mid-sprint surprises about dependencies that should have been identified earlier.
• Stories blocked because the Product Owner is unavailable to answer questions.
• Stories that grow during the sprint because the team didn't realize how big they were.
• Reviewer or QA blocked because no test approach was agreed upfront.

A team that has rough agreements about what "ready" means catches most of these before they cost sprint capacity.

The Anti-Pattern

DoR becomes harmful when treated as a hard gate. Symptoms:

• Stories blocked from sprint: items that don't meet every checkbox can't enter, even when the team could clearly work with what's there.
• Refinement becomes a bureaucracy: stories pingpong between Product and Engineering trying to satisfy criteria nobody can fully meet.
• Loss of agility: high-value urgent items get blocked by procedural concerns.
• DoR as a wall: developers point at the DoR to refuse work; Product Owners point at the DoR to refuse engagement. Both sides hide behind it.

The Scrum Guide's omission of DoR (it explicitly defines DoD but not DoR) reflects this concern. Scrum.org has written critically about DoR-as-gate.

DoR as Guideline vs. Gate

The honest middle position:

• DoR as guideline: the team has explicit criteria for what makes a story ready, used as a checklist during refinement and as a self-check before sprint planning. Items that fall short are flagged but not blocked.
• DoR as gate: items that don't meet every criterion are mechanically excluded. Sprint planning becomes adversarial.

Mature teams use DoR as guideline. The team's judgment determines whether the story is ready in spirit; the criteria are a memory aid, not a contract.

Building a Working DoR

1. Start from problems the team has had

Don't copy a generic DoR from the internet. Look at recent stories that went badly — what was missing that, if it had been there, would have prevented the issue? That's the team's real DoR.

2. Keep it short

5-7 items is plenty. Long lists become checklists nobody fully reads.

3. Make it observable

"Has clear acceptance criteria" is observable; "is well-understood" is not. Each criterion should be verifiable.

4. Treat it as guideline, not gate

The team's judgment matters more than the checklist. A story that violates one criterion but is clearly ready can still be pulled.

5. Revisit when stories go badly

If a sprint had stories that went sideways, the retro should examine whether DoR criteria would have caught the problem. Add, remove, or refine as the team learns.

Common Pitfalls

• Generic DoR copied from a book: doesn't reflect the team's actual problems; gets ignored or argued about.
• DoR as hard gate: produces bureaucracy, blocks high-value work, creates adversarial Product/Engineering dynamics.
• Long checklists nobody fully checks: 20-item DoRs become decoration. Cap at 5-7 items.
• Vague criteria: "ready" needs to mean something observable, not subjective.
• DoR never updated: a team's DoR three years in should look different from year one. Static DoRs stop reflecting reality.
• DoR used to push work back without coaching: when items don't meet DoR, the team's job is to help refine them, not just reject them.

Coaching Tips

Build from Pain

Don't copy a DoR. Build one from stories that went badly. The team's real DoR is what would have prevented those failures.

Cap the Length

5-7 items maximum. Longer lists become decoration nobody actually checks against.

Use as Guideline

Treat the DoR as memory aid, not as gate. A team that uses it to block work creates adversarial dynamics.

Make Criteria Observable

"Clear acceptance criteria" is verifiable. "Well-understood" is subjective. Push for criteria the team can actually check.

Coach, Don't Reject

When items don't meet DoR, the response is to help refine them, not to push them back. Refusing work without coaching produces the bureaucracy critics warn about.

Update When Pain Changes

A DoR three years old probably reflects problems the team no longer has. Revisit periodically; remove what's no longer needed.

Summary

Definition of Ready is one of the more contentious practices in the Agile catalog, mostly because the same words describe very different practices. A team using DoR as a working guideline gets value out of it; a team using DoR as a stage gate produces the bureaucracy that critics correctly call out as anti-Agile.

The honest practice is treating DoR as the team's shared shorthand for "we've seen this go wrong before in these specific ways, and we'd like to avoid it again." The checklist doesn't have to be perfect; it has to capture the team's actual learned wisdom about what makes stories deliverable. Used that way, it's a small investment that produces noticeable sprint quality improvement.

Back to Agile Delivery