The Definition of Done (DoD) and Definition of Ready (DoR) are two of the most practical and highest-impact quality tools in the Agile project manager’s toolkit. Despite being used in the same breath and often confused with each other, they serve entirely different purposes, apply at different points in the delivery process, and address different quality failure modes. Understanding the precise difference between definition of done vs definition of ready — and implementing both rigorously — is one of the most reliable ways to improve sprint predictability, reduce waste, and build stakeholder confidence in Agile delivery quality.
What Is the Definition of Done?
The Definition of Done is a formal, shared checklist of the conditions that must be satisfied before any work item can be considered complete. It defines “done” consistently across the team, eliminating the ambiguity that arises when different team members have different implicit expectations about what completion means. In the absence of a DoD, “done” means whatever the person finishing the work wants it to mean — which might be “I finished coding” (ignoring testing), “I finished testing” (ignoring code review), or “it passed UAT” (ignoring documentation). This ambiguity is one of the most common sources of late-sprint surprises, rework, and technical debt accumulation.
According to the Scrum Guide, the Definition of Done creates transparency and provides a shared understanding of what work is required to create releasable increments. It is a quality commitment by the entire Scrum team, not a checklist imposed by management. A DoD that team members do not own will not be respected under delivery pressure.
What Is the Definition of Ready?
The Definition of Ready is a checklist of the conditions that must be met before a user story or work item can be pulled into a sprint for development. It defines the minimum information and clarity required for the team to begin work on an item with confidence — to be able to plan it, estimate it accurately, and complete it within a single sprint. A story that does not meet the DoR is not ready for sprint planning; pulling unready stories into a sprint is the primary cause of mid-sprint scope changes, ambiguity-driven delays, and sprint goal failures.
The DoR is sometimes described as the “Definition of Done for the Product Owner” — the quality bar that requirements must clear before development begins, analogous to the quality bar that development must clear before a story is considered complete. Both serve the same underlying purpose: preventing low-quality inputs from propagating forward through the delivery process where they become more expensive to address.
The Fundamental Difference
The core distinction is temporal and directional. The Definition of Ready is applied at the entry gate — before a story enters the sprint. It asks: “Is this story prepared well enough to work on?” The Definition of Done is applied at the exit gate — before a story is declared complete. It asks: “Has this story been finished thoroughly enough to ship?” The DoR prevents waste from starting work on under-specified stories. The DoD prevents waste from shipping incomplete or low-quality work.
Crafting an Effective Definition of Done
A well-designed DoD is specific, testable, and owned by the whole team. It should be developed collaboratively in a team workshop, agreed by consensus, and stored visibly in the team’s workspace (physical and digital). It should be reviewed and evolved at retrospectives as the team’s quality standards mature. Common DoD criteria include:
- All acceptance criteria specified in the user story are met and verified
- Unit tests written and all passing (coverage threshold met)
- Integration tests passing in the CI pipeline
- Code peer-reviewed and all review comments resolved
- No new security vulnerabilities introduced (automated scan passing)
- Documentation updated (API docs, user guides, architecture diagrams as applicable)
- Deployed to the staging environment and smoke-tested
- Product Owner has formally accepted the story
A DoD that includes only “development complete” or “tests passing” is too thin to prevent the most common quality failures. A DoD that includes 30 items is too heavy to apply consistently under sprint pressure. Most mature Agile teams settle on 8–12 items that represent their non-negotiable quality floor.
Crafting an Effective Definition of Ready
The DoR should reflect the minimum information the development team needs to plan, estimate, and complete a story confidently within a single sprint. Common DoR criteria include:
- User story written in agreed format (As a [role] I want [capability] so that [benefit])
- Acceptance criteria written and agreed with the Product Owner
- All external dependencies identified and either resolved or explicitly managed
- Story estimated by the development team (in story points or complexity)
- Story is small enough to be completed within a single sprint
- UI mockups or wireframes available (if applicable)
- Non-functional requirements specified (performance, security, accessibility)
“The Definition of Done and Definition of Ready together form a quality corridor that work must pass through in both directions. DoR ensures you start the right work. DoD ensures you finish it properly.” — Mike Cohn, Agile practitioner and author
Common DoD and DoR Anti-Patterns
Several patterns consistently undermine the value of DoD and DoR in practice. The most damaging anti-patterns include: the team “waiving” DoD criteria under sprint pressure (“we’ll clean it up next sprint”), creating a DoD that is aspirational rather than enforced, a DoR so demanding that most stories never qualify and the team starves for sprint work, and treating DoD and DoR as management tools rather than team-owned quality standards. All of these erode the quality foundation that DoD and DoR are designed to provide and signal a need for team-level coaching on quality culture.
DoD vs DoR Quick Reference
| Dimension | Definition of Done (DoD) | Definition of Ready (DoR) |
|---|---|---|
| Applied when | Before declaring work complete | Before pulling into a sprint |
| Owned by | Entire Scrum team (Dev + PO) | Product Owner + Dev team |
| Prevents | Shipping incomplete/low-quality work | Starting under-specified work |
| Failure symptom | Technical debt, bugs in production | Mid-sprint scope changes, ambiguity |
| Reviewed at | Sprint review / retrospective | Backlog refinement / retrospective |
Key Takeaways
- The Definition of Done is an exit gate — applied before declaring work complete. The Definition of Ready is an entry gate — applied before pulling work into a sprint. They serve opposite but complementary quality control functions.
- A missing or unenforced DoD is the primary driver of technical debt accumulation, production defects, and late-sprint surprises in Agile projects.
- A well-designed DoD has 8–12 specific, testable criteria that represent the team’s non-negotiable quality floor — aspirational criteria that are routinely waived undermine its purpose entirely.
- The DoR prevents the waste of starting work on under-specified stories — mid-sprint scope changes and ambiguity-driven delays are almost always caused by pulling unready stories into the sprint.
- Both DoD and DoR must be team-owned and team-enforced — management-imposed checklists that teams do not believe in will not be respected under delivery pressure.
- Review and evolve both DoD and DoR at retrospectives as the team’s quality standards and practices mature — they should become more rigorous over time, not more flexible.
