Definition of Ready (DoR)

Definition

The Definition of Ready (DoR) is a checklist agreed by an agile team describing the minimum characteristics a backlog item must have before it can be pulled into a sprint (or, in flow-based systems, into active work). It is the counterpart of the Definition of Done: DoD ends a story cleanly, DoR starts one cleanly. Teams without a DoR routinely pull half-defined stories into sprints, spend the sprint clarifying instead of building, and finish with velocity down and morale lower. Teams with a well-tuned DoR spend far less time in the weeds — the story arrives with enough shape to build.

Typical DoR Contents

• Clear user story: As a <user>, I want <capability>, so that <outcome>.
• Acceptance criteria written and reviewed.
• Dependencies identified and unblocked (or a clear plan).
• Sized (story points, T-shirt size, or ideal days).
• UX / design artefacts attached if needed.
• Data availability confirmed for testing.
• Non-functional requirements considered (performance, security, accessibility).
• The team can explain the story in one sentence.

Real-World IT / Agile Example

A payments-team of nine engineers had a DoR of eight items. Their sprint planning meetings used to take three hours and produce brittle sprints; three months after introducing DoR, planning took 45 minutes and their sprint-completion rate rose from 62% to 89%. The mechanism was not magic — refinement moved upstream. The Product Owner learned to bring only ready stories to planning. Unready stories went back to refinement. The visible improvement in the burn-down was, largely, the invisible improvement in refinement discipline.

Real-World Construction Example

The DoR concept has a strong parallel in Last Planner System constraint removal. Before a task can be pulled into the Weekly Work Plan, the team confirms the six "make-ready" conditions: design complete, materials on site, prerequisite work done, labour available, equipment available, information available. A fit-out contractor introduced this as a formal checklist and their weekly commitment reliability (Plan Percent Complete) rose from 54% to 82% over six weeks. Same principle: never start work you have not made ready.

Where DoR Fails

• DoR becomes a bureaucracy. If it takes three ceremonies to declare a story ready, refinement has become an anti-pattern.
• DoR is used as a gate to block Product. "Not ready — try again next sprint" without a genuine reason destroys trust.
• DoR is confused with a full design specification. A ready story is not a fully solved story; it has enough shape to start.
• The DoR is written once and never revisited. Teams should tune the DoR every few months as the product matures.

Expert Tips

• Start small. Five items on the first DoR is plenty. Add more only if you can point to a specific pain that a new item would prevent.
• Never let anyone impose a DoR from outside. The team owns it; the team enforces it.
• Distinguish "invest in refinement" from "block the sprint". If a story is 80% ready and the team can start, sometimes the right call is to start and clarify in the sprint.
• Retrospect on refinement quality. A retro question every few sprints: "Were the stories ready when we started them?" If not, tighten the DoR.
• Track "unready stories brought to planning". This one metric is the sharpest indicator of refinement health.

Common Mistakes

• Copying a generic DoR from a blog without adapting to the team.
• Refusing every story that fails a single item — legalistic and unhelpful.
• Treating DoR as the Product Owner's checklist rather than the whole team's.
• No connection between DoR and refinement — the DoR just sits on a wiki page.
• Using DoR to shift blame to Product when the sprint fails; that is a symptom of team dysfunction, not a governance problem.

Practical Lessons Learned

• The best teams treat DoR as a conversation starter, not a gate. "Is this ready enough?" is a healthier question than "does it pass line 4?"
• Sprints that fail almost always fail because unready work was pulled in — not because the team was too slow.
• The single biggest improvement most teams can make is to move 30 minutes of clarification from mid-sprint to pre-sprint refinement.

Key Takeaways

• DoR is the entry gate to a sprint; DoD is the exit gate.
• Ready ≠ fully specified; it means "we can start without immediate blockers".
• Teams that refine well need only a light DoR; teams that refine poorly need a heavier one until the habit sticks.
• The construction Last Planner make-ready check is the same idea; it works for the same reasons.

Related Encyclopedia Entries

• Definition of Done
• Backlog Refinement
• Last Planner System
• User Story Mapping

Related Research Articles, Case Studies & Tools

• Agile Templates
• Project Controls Academy: Agile Delivery
• Refinement effectiveness studies