Definition of ready
The Definition of Ready (DoR) specifies what must be true about a backlog item before the team commits to implementing it. It's a quality gate for incoming work, ensuring that items entering a sprint are sufficiently understood, sized, and prepared. Where the Definition of Done ensures quality outputs, the Definition of Ready ensures quality inputs.
Why it matters
Developers waste enormous time on work that isn't ready. Missing requirements, unclear acceptance criteria, unavailable dependencies, and unanswered questions block progress and force context-switching. A story that looks simple in planning becomes a multi-sprint saga when nobody clarified what "user authentication" actually means.
The Definition of Ready prevents this waste by making readiness explicit. If an item doesn't meet the criteria, it doesn't enter the sprint. This creates pressure for proper preparation - product managers, designers, and stakeholders know that vague items won't be accepted.
For teams, the DoR provides legitimate grounds to push back on poorly defined work. Instead of being seen as uncooperative for refusing unclear items, they're following agreed process. The DoR makes preparation a shared responsibility rather than a point of conflict.
Common ready criteria
A typical Definition of Ready includes:
Clear description - The item has a written description that the team understands. Not just a title, but enough context to grasp what's being requested.
Acceptance criteria defined - Specific, testable conditions that determine when the work is complete. The team and product owner agree on what success looks like.
Dependencies identified - Any prerequisite work is complete, or dependencies are clearly documented with resolution plans. The team won't be blocked waiting for something outside their control.
Sized appropriately - The item is small enough to complete within a sprint. Large items have been broken down. The team has estimated effort.
Design decisions made - For items requiring design, mockups or wireframes are available. Key UX questions are answered.
Technical approach discussed - The team has at least briefly considered how to implement the work. Major technical questions have answers.
Value articulated - The team understands why this work matters. Who benefits and how?
Applying the definition of ready
The DoR typically gets applied during backlog refinement and sprint planning:
During refinement - Items are discussed and evaluated against ready criteria. Those that don't meet the standard go back for more preparation. This conversation happens before planning, not during it.
During sprint planning - Only items meeting the DoR are candidates for commitment. If something isn't ready, it doesn't enter the sprint regardless of priority.
Throughout the sprint - If an item reveals itself as not actually ready once work begins (missing information emerges, scope was unclear), that's a signal to improve the DoR or refinement process.
The DoR should be documented, visible, and referenced explicitly. "Is this item ready?" should be a standard question, answered against specific criteria rather than gut feeling.
Definition of ready vs. definition of done
These complement each other as quality gates at different stages:
| Aspect | Definition of Ready | Definition of Done |
|---|---|---|
| When applied | Before work starts | After work completes |
| What it ensures | Work is prepared for development | Work meets quality standards |
| Who benefits most | Developers (clear inputs) | Stakeholders (reliable outputs) |
| Focus | Clarity and preparedness | Completeness and quality |
Both are team agreements. Both help establish shared expectations. Both should evolve as the team learns what works.
Potential pitfalls
Weaponized DoR becomes a tool to avoid work. Teams that rigidly refuse everything that isn't perfectly specified can hide behind the DoR rather than collaborating to prepare work.
False precision creates a DoR so detailed that meeting it requires more effort than building the feature. The DoR should ensure adequate preparation, not perfect preparation.
Waterfall creep happens when the DoR demands so much upfront specification that agility disappears. The DoR should support iterative development, not prevent it.
Ignoring the DoR under schedule pressure defeats its purpose. When items enter sprints despite not being ready, the DoR becomes meaningless. Discipline matters.
Static criteria fail to evolve as the team changes. What a mature team needs for readiness differs from what a new team needs. Review and adjust the DoR periodically.
When to skip the dor
Some legitimate situations warrant flexibility:
Emergency fixes need immediate attention regardless of formal readiness. Production is down - you don't need acceptance criteria to fix it.
Exploration work like spikes is inherently uncertain. Requiring detailed specifications for research tasks defeats their purpose.
Very small items might be obviously ready without formal evaluation. Common sense should prevail over bureaucratic process.
The DoR exists to improve outcomes, not to create process for its own sake. When rigid application would harm more than help, appropriate judgment should override mechanical rule-following.
A well-calibrated Definition of Ready ensures that teams spend their time building rather than wondering what to build. It shifts preparation work to where it belongs - before development starts - and makes clear that proper preparation is everyone's responsibility.
