Definition of Ready vs. Definition of Done: Closing the Quality Gap
Most Agile teams have a Definition of Done. Far fewer have a Definition of Ready. Both are essential — and the gap between them is where quality problems, rework, and planning surprises consistently hide.
The Quality Gap Hidden in Plain Sight
Every mature Agile team has a Definition of Done — the checklist of conditions a story must meet before it can be called complete. Tests pass, code reviewed, documentation updated, deployed to staging: the specific criteria vary by context, but the principle is universal.
The Definition of Ready receives far less attention, and that asymmetry creates a quality gap that manifests as planning surprises, mid-sprint scope changes, and chronic rework.
The Definition of Ready answers a different question: what conditions must be met before a story can enter a sprint? While the DoD governs completion, the DoR governs inception — ensuring that teams don't pull poorly understood, under-specified work into a sprint commitment and discover the gaps at the worst possible moment.
Why the Definition of Ready Matters
It Shifts Discovery Earlier
Requirements ambiguity has a cost that scales with how late it's discovered. Ambiguity discovered during backlog refinement costs an hour of conversation. The same ambiguity discovered during development costs a day of rework. Discovered during testing, it costs a sprint. Discovered in production, it costs a customer.
The Definition of Ready is the mechanism that drives discovery into backlog refinement — the lowest-cost, lowest-risk environment for resolving ambiguity.
It Protects Sprint Commitments
Sprint planning is a commitment event. When teams pull stories that don't meet the DoR, they're committing to work they don't fully understand. The result is predictable: stories that seemed like two-point items during planning turn into multi-day discussions about edge cases, missing designs, or unclear dependencies.
A consistently applied DoR gives sprint planning reliability. Teams know that items at the top of the backlog are genuinely ready to develop — not just roughly scoped and optimistically estimated.
It Distributes Preparation Work Appropriately
Without a DoR, preparation work often happens informally and unevenly. Some developers clarify stories before pulling them; others don't. Some Product Owners provide detailed acceptance criteria; others provide titles and assume the team will figure it out.
The DoR makes preparation expectations explicit and shared. It's no longer up to individual initiative — it's a team standard.
Crafting a Definition of Ready
A strong DoR is specific to your team's context but typically includes:
**Story is understood.** The team has discussed the story and the acceptance criteria in sufficient depth that any member could implement it. There are no "we'll figure this out when we get there" items.
**Acceptance criteria are defined.** Clear, testable conditions exist for the core scenarios and the most important edge cases. These are written from the user's perspective, not the developer's.
**Dependencies are identified.** Any dependencies on other teams, systems, or deliverables are explicit. Blocking dependencies are resolved (or the story isn't ready). Non-blocking dependencies are acknowledged and risk-assessed.
**Size is agreed.** The team has estimated the story in whatever sizing approach they use, and the estimate reflects a genuine shared understanding — not a split vote with unresolved disagreement.
**Design assets are available.** If the story requires specific UX or visual design, those assets exist and have been reviewed. Stories that enter development without design direction consistently generate mid-sprint rework.
**Technical approach is clear.** For complex or novel technical work, the team has done sufficient exploration (spike) to understand the approach. Unknown technical paths are not ready.
Crafting a Definition of Done
The DoD is the more commonly discussed checklist, but it's worth examining what a high-quality DoD actually contains — and what teams frequently omit.
**Code is complete and reviewed.** Functional and meets coding standards. Peer-reviewed by at least one other developer.
**Tests are written and passing.** Unit tests, integration tests, and any required acceptance tests pass in the CI pipeline. Test coverage meets the team's agreed minimum threshold.
**No new technical debt is introduced without acknowledgment.** Any shortcuts or known limitations are documented and added to the technical backlog as explicit items.
**Acceptance criteria are met.** The story satisfies all conditions defined in the DoR. The Product Owner has reviewed and confirmed.
**Non-functional requirements are met.** Performance benchmarks, accessibility standards, security requirements, and any other cross-cutting concerns relevant to this story are verified.
**Documentation is updated.** API documentation, runbooks, user guides — whatever documentation the story affects is current.
**Story is deployable.** The increment can be deployed to production (or a production-equivalent environment) at any time. "Deployable but not deployed" is a valid state; "not deployable" is not done.
Making Them Living Documents
Both the DoR and DoD should evolve. When teams consistently encounter the same type of gap — stories that miss DoR criteria in the same way, or done items that consistently have the same deficiency — the checklists should be updated to address the pattern.
The retrospective is the natural venue for DoR and DoD reviews. A quarterly pass through both documents, asking "are these still the right criteria?" and "are there consistent gaps we're not capturing?" keeps them relevant rather than ceremonial.
The DoR and DoD are not bureaucratic overhead. They're the team's shared definition of what "ready" and "done" mean — and that shared definition is the foundation of both delivery quality and team trust.
Ready to put this into practice?
Join a SAFe certification course and master agile at scale.
Browse Courses →
