In agile teams the terms “Definition of Ready” (DoR) and “Definition of Done” (DoD) are often mentioned together, but they serve distinct purposes. DoR is the gate that lets a story into a sprint; DoD is the gate that lets a story out. Treating them as separate, well‑maintained checklists prevents half‑baked work from contaminating the flow and keeps quality predictable.
Definition of Ready
A story is estimable when the team understands the scope well enough to size it. This means the description is clear, dependencies are identified, and any required designs or data are available. Without this clarity, the team spends sprint time debating what the work actually entails.
Acceptance criteria set means that the product owner has written clear, testable conditions that define when the story is complete. These criteria act as the contract between the PO and the development team and give the QA group a concrete basis for verification.
Definition of Done
Code reviewed & merged ensures that every change meets the team’s quality bar. A peer review catches defects early, enforces coding standards, and guarantees that the code is integrated into the main branch without conflicts.
Tested and demo‑ready requires that QA has passed all acceptance tests and that the increment can be deployed to a staging environment for a stakeholder demo. This eliminates the “it works on my machine” problem and guarantees that the story can be shown to the PO at sprint review.
Who Owns What
The Product Owner owns Ready. The PO is responsible for backlog refinement, ensuring that items meet the DoR before sprint planning. This ownership gives the PO authority to pull items back for clarification rather than forcing them into a sprint.
The Team owns Done. The development team collectively agrees on a DoD that applies to every story. This shared agreement avoids the “done” meaning different things to developers, testers, and the PO.
Why It Matters
Fewer mid‑sprint surprises: A solid DoR stops ambiguous or incomplete stories from entering the sprint, reducing the need for re‑planning or emergency clarification.
Consistent quality bar: A shared DoD ensures that “done” has a single definition across the team, preventing the delivery of work that still needs rework after the sprint ends.
Do / Avoid
Do
- Review both checklists during the retrospective, not just once at planning.
- Keep DoR light; it is a gate, not an essay.
- Make DoD visible on the board so everyone can see the quality expectations at a glance.
Avoid
- Don’t let the PO and developers disagree on “done” mid‑sprint. Resolve differences before the sprint starts.
- Don’t skip DoR to meet sprint‑planning deadlines; a rushed entry creates hidden work later.
- Don’t treat DoD as fixed forever; revisit it when the team’s capabilities or product needs change.
A clear, shared understanding of Ready and Done keeps the sprint predictable, the backlog healthy, and the product moving forward.
Top comments (0)