Definition of Ready-(DoR)
1. Purpose
The Definition of Ready (DoR) establishes a shared understanding of what conditions a Product Backlog Item (PBI) must meet before it can be accepted into a Sprint.
The DoR helps the team to:
Reduce uncertainty and rework during the Sprint
Improve Sprint predictability and flow
Ensure PBIs are actionable and well‑understood
Enable meaningful Sprint Planning and commitments
A PBI that does not meet the DoR should not be pulled into a Sprint
A PBI that does not meet the DoR should not be pulled into a Sprint without team agreement on the underlying risks.
2. Scope
This Definition of Ready applies to:
User Stories
Bugs / Defects
Technical Enablers / Spikes (with appropriate adjustments)
The DoR is used:
During Product Backlog Refinement
As an input to Sprint Planning
By the entire Scrum Team (Product Owner, Developers, QE, UX, DevOps, Scrum Master)
3. Mandatory Readiness Criteria
A PBI is considered Ready when all of the following criteria are met.
3.1 Clear Description
The PBI is clearly written and understandable by the whole team
The business or user problem is explicitly stated
The value or outcome is evident
3.2 Defined Acceptance Criteria
Acceptance Criteria are documented
Acceptance criteria are clear, testable, and unambiguous
The team agrees they understand what “done” means for this item
3.3 Small Enough to Complete in a Sprint
The PBI is sized appropriately for completion within one Sprint
If too large, it has been split into smaller PBIs
3.4 Prioritized
The PBI is ordered relative to other backlog items
The Product Owner confirms it is a near‑term priority
3.5 Dependencies Identified
Known dependencies (technical, team, external, or data) are identified
Dependencies are resolved, mitigated, or explicitly accepted by the team
3.6 Acceptance by the Team
Developers and testers agree the PBI is feasible
No major unanswered questions remain
Risks and assumptions are visible and understood
PBI is pointed with QE time included in estimate
PBI is marked or tagged to identify sprint readiness
4. Advanced Readiness Criteria
These criteria are recommended for higher maturity teams or complex work but are not mandatory.
4.1 UX / Design Readiness
UX designs, wireframes, or prototypes are available (if applicable)
Design decisions and constraints are documented
Accessibility and usability considerations are addressed
4.2 Technical Considerations
High‑level technical approach is discussed
Architecture or integration impacts are understood
Performance, security, or compliance considerations are identified
4.3 Test Strategy
Test approach is outlined (e.g., unit, integration, automation)
Non‑functional requirements (performance, reliability, security) are defined where relevant
4.4 Data & Environment Readiness
Required data sources are identified and accessible
Required environments, feature flags, or configuration are available or planned
5. Team Responsibilities
5.1 Product Owner
Ensures PBIs are well‑described, prioritized, and valuable
Provides clarity on business goals and acceptance criteria
Collaborates with stakeholders and the team during refinement
5.2 Developers
Assess feasibility and technical complexity
Identify risks, dependencies, and technical gaps
Help split and refine oversized PBIs
5.3 QE / Test Engineers
Validate testability of Acceptance Criteria
Identify edge cases and non‑functional requirements
Contribute to quality and readiness discussions
5.3.1 In-Sprint Automation
API models documented or prioritized with development
UI selectors identified or prioritized with development
5.4 UX / Design (when applicable)
Provide designs, flows, or usability guidance
Clarify user experience expectations
Ensure accessibility and consistency considerations are addressed
5.5 Scrum Master
Facilitates backlog refinement and DoR discussions
Ensures DoR is understood and consistently applied
Helps the team improve DoR over time
6. Continuous Improvement
The Definition of Ready is not static
The team reviews and evolves the DoR periodically
Adjustments are made based on delivery outcomes, retrospectives, and team maturity