Definition of Ready vs Definition of Done: What's the Difference?
DoR and DoD are two sides of the same coin. Learn when to use each, how they complement each other, and why most teams need both.
In Scrum, Definition of Ready (DoR) and Definition of Done (DoD) are both quality gates — but they operate at different points in the workflow. DoR guards the entrance to the sprint. DoD guards the exit. Together, they create a quality sandwich around your sprint work.
Quick comparison
| Definition of Ready | Definition of Done | |
|---|---|---|
| When | Before sprint planning | Before closing an issue |
| Purpose | Ensure work is well-defined before starting | Ensure work meets quality standards before shipping |
| Who owns it | PO + team during refinement | Team + tech lead during review |
| Typical criteria | Description, acceptance criteria, estimate, assignee, priority | Subtasks complete, code reviewed, tests passing, documentation updated |
| Failure mode | Mid-sprint confusion, scope changes, blocked developers | Bugs in production, inconsistent quality, "done but not really done" |
| Scrum Guide | Not in the official Scrum Guide, but widely adopted | Explicitly required by the Scrum Guide |
Definition of Ready in detail
A DoR answers the question: "Is this issue clear enough for a developer to start working on it right now?"
Typical DoR criteria include:
- The issue has a clear description (not just a title)
- Acceptance criteria are written and agreed upon
- The team has estimated the issue (story points or time)
- Dependencies are identified and linked
- Designs or mockups are attached (if applicable)
The DoR is owned by the whole team, not just the Product Owner. During backlog refinement, the team reviews upcoming issues and flags anything that doesn't meet the DoR. These issues stay in the backlog until they do. For a copy-paste-ready DoR with 9 criteria mapped to Jira fields, see our Definition of Ready template for Jira.
Definition of Done in detail
A DoD answers the question: "Is this issue complete enough to ship to users?"
Typical DoD criteria include:
- All subtasks are completed
- Code has been reviewed and approved
- Tests are written and passing
- Documentation is updated
- Issue has a resolution set in Jira
- No open blockers or unresolved comments
The Scrum Guide explicitly states that a DoD is required. It creates transparency about what "Done" means across the team, so everyone has the same standard. Without it, "done" often means "I pushed my code" — ignoring tests, reviews, and documentation. For a full 10-criteria DoD template mapped to Jira fields, see Definition of Done template for Jira.
Why you need both
Using only DoR catches input problems but not output problems. Using only DoD catches quality issues but doesn't prevent wasted effort on poorly defined work. Together they provide end-to-end protection:
- DoR prevents wasted sprints. If an issue is unclear, the team will spend time asking questions, waiting for answers, and reworking — all during a time-boxed sprint.
- DoD prevents escaped defects.If "done" doesn't include code review and testing, bugs reach production.
- Together they create predictability. When input quality is high (DoR) and output standards are consistent (DoD), velocity stabilizes and sprint commitments become reliable.
Implementing both in Jira
Most teams document their DoR and DoD in a Confluence page or team wiki. The problem is that nobody checks it during the actual workflow — it becomes shelfware.
A better approach is to embed both checks directly into Jira:
- Jira Automation can validate field conditions and block transitions, but maintaining complex multi-rule automations is painful.
- Dedicated tools like ReDoprovide separate DoR and DoD tabs on every issue, each with its own criteria and real-time scoring. The score is visible on the issue itself — you don't need to open a wiki to check if criteria are met.
The key advantage of embedding DoR/DoD in Jira (rather than a wiki) is that it creates a feedback loop: criteria that are consistently unmet get noticed and addressed, because they're visible on every single issue.
Common patterns
Pattern 1: DoR only (starter teams)
Start with DoR to reduce mid-sprint confusion. Once backlog quality improves, add DoD to raise the bar on output.
Pattern 2: DoD only (mature teams)
Some teams have strong refinement habits and don't need formal DoR. They focus on DoD to ensure consistent release quality. This is common in teams with experienced POs.
Pattern 3: Both (recommended)
Use both simultaneously. ReDo supports this with separate tabs — DoR visible during refinement/sprint planning, DoD visible during development and review.
Key takeaway
DoR and DoD are complementary, not competing. DoR prevents garbage in, DoD prevents garbage out. Most teams benefit from implementing both — start with one if that's easier, but plan to adopt the other within a quarter.