In agile teams the terms Definition of Ready (DoR) and Definition of Done (DoD) are often mentioned together, yet they serve distinct purposes. A clear DoR filters work before it lands in a sprint, while a solid DoD guarantees that what leaves the sprint truly meets the team’s quality standards. Below is a concise guide to the two checklists, ownership, and why they matter.
Definition of Ready
A story is ready when the team can estimate it and has enough detail to begin work.
- Story is estimable – The team understands the scope well enough to size the story using story points, t-shirt sizes, or another method. Ambiguities that would prevent a reliable estimate are resolved.
- Acceptance criteria set – Clear, testable conditions define what “done” looks like. Each criterion is specific enough that QA can verify it without guesswork.
Having these items in place prevents the sprint from being derailed by unknowns that surface only after work has started.
Definition of Done
A story is done when it meets the team’s agreed quality bar and is ready for release or further integration.
- Code reviewed & merged – The implementation passes peer review, adheres to coding standards, and is merged into the main branch.
- Tested and demo‑ready – Automated and manual tests pass, QA signs off, and the feature can be demonstrated in a sprint review. It is deployable to a staging environment without additional work.
The DoD ensures that “done” means the same thing to developers, testers, and the product owner.
Who Owns What
- PO owns Ready – The Product Owner (or proxy) is responsible for backlog refinement, ensuring each story meets the DoR before sprint planning. This ownership keeps the backlog clean and the sprint planning meeting focused.
- Team owns Done – The development team collectively defines the DoD and applies it to every story. Because the team creates the code, runs the tests, and delivers the increment, they are best positioned to set realistic quality criteria.
Clear ownership avoids the classic “who decides when a story is ready/done?” debate during the sprint.
Why It Matters
- Fewer mid‑sprint surprises – A robust DoR stops ambiguous or under‑specified stories from entering the sprint, reducing the need for re‑planning or scope changes.
- Consistent quality bar – A shared DoD eliminates the “my definition of done” problem, ensuring every increment meets the same standards for code quality, testing, and deployability.
When both checklists are respected, the team can deliver predictable, high‑quality increments each sprint.
Do / Avoid
Do
- Review both checklists at the retrospective, not just once per sprint. Continuous inspection keeps them relevant.
- Keep the DoR light; treat it as a gate, not an essay. Over‑engineering the ready criteria can stall backlog refinement.
- Make the DoD visible on the board or in the sprint backlog so everyone can see the acceptance point at a glance.
Avoid
- Don’t let the PO and developers disagree on “done” mid‑sprint. Resolve any DoD conflicts during backlog refinement.
- Don’t skip DoR to meet sprint‑planning deadlines; a rushed sprint starts with technical debt.
- Don’t treat the DoD as immutable. Revisit it regularly to incorporate new testing tools, architectural changes, or regulatory requirements.
A disciplined approach to Ready and Done turns the sprint from a guessing game into a reliable delivery engine.
Top comments (0)