Definition of Ready

Purpose

The Definition of Ready (DoR) prevents half-baked work from entering a Sprint. By agreeing upfront on what "ready" means, teams reduce mid-Sprint surprises, scope creep, and carry-over.

At a glance

How to run

1. Context (5 min) — Explain the purpose. Share examples of items that entered Sprints unready and the problems that followed.
2. Brainstorm criteria (10 min) — Silent brainstorm: each person writes criteria on sticky notes.
3. Cluster and discuss (15 min) — Group similar criteria. Discuss each: Is it essential? Is it practical to verify before Sprint Planning?
4. Vote (5 min) — Dot voting or thumbs to reach consensus on each criterion.
5. Write the DoR (5 min) — Formalize the agreed criteria.
6. Agree on the process (5 min) — When and how will readiness be checked? (e.g., at Backlog Refinement, before Sprint Planning.)

Materials needed

• Sticky notes and markers
• Examples of ready vs. not-ready items from past Sprints
• Whiteboard or digital collaboration tool

Pitfalls & common mistakes

• DoR becomes a gate — It should be a guide, not a bureaucratic checkpoint that blocks all work.
• Too many criteria — Keep it to 5–8 essential criteria. A 20-point checklist will be ignored.
• Never updated — Review every quarter or when readiness problems persist.
• PO does all the work alone — Readiness is a team responsibility; developers help refine items.

Inclusion & accessibility

• Use silent brainstorming first to capture all voices.
• Write criteria in plain language accessible to all roles.
• Post the DoR visibly so new team members learn it immediately.

Variations

• Combined DoR + DoD workshop — Run both back to back in a 90-minute session.
• INVEST checklist — Use the INVEST criteria (Independent, Negotiable, Valuable, Estimable, Small, Testable) as a starting framework.
• Traffic-light readiness — Rate each item as red/amber/green against the DoR at refinement.

When NOT to use this

• If the team consistently pulls well-understood items into Sprints without issues — the DoR adds overhead without value.
• If the DoR is being used to blame the PO for unready items — fix the culture first.

Source & further reading

• Schwaber, K. & Sutherland, J. (2020). *The Scrum Guide*. scrumguides.org
• Rubin, K. (2012). *Essential Scrum*. Addison-Wesley.