Comprehensive, immediately-usable rules for establishing and maintaining a Definition of Ready (DoR) across Scrum, Kanban, XP and Scrumban teams.
Your last sprint planning session ran two hours overtime. Half the stories were missing acceptance criteria, three had unresolved dependencies, and your team spent more time clarifying requirements than committing to work. Sound familiar?
Every development team knows this frustration: you're deep into sprint planning when someone asks "Wait, what exactly does this story need to do?" or "Who's handling the API integration for this?" Suddenly, your crisp 30-minute planning session becomes a 2-hour requirements discovery workshop.
The real cost isn't just meeting time – it's the cascade of problems that follow:
A Definition of Ready (DoR) is your team's quality gate – a checklist that every backlog item must pass before it can enter a sprint. Think of it as your development firewall: if a story doesn't meet every criterion, it doesn't make it into active work.
Here's what changes immediately:
Sprint Planning → Unclear Story → Mid-Sprint Clarification →
Developer Blocked → Emergency PO Meeting → Story Spillover →
Missed Sprint Goal → Frustrated Retrospective
Backlog Item → DoR Checklist Review → Ready for Sprint →
Clean Development → Predictable Delivery → Consistent Velocity
Sprint Planning Efficiency: Teams report 40-60% shorter planning sessions when stories consistently pass DoR review during refinement instead of discovery during planning.
Developer Productivity: No more "I can't start this story because..." conversations. Developers know exactly what to build and can begin coding immediately.
Predictable Delivery: Sprint commitments become reliable because the work is actually ready to start, not "ready to figure out what we're building."
Start with this proven template and customize for your context:
## Definition of Ready Checklist
### Business Value & Requirements
- [ ] Business value clearly articulated and approved by Product Owner
- [ ] User story follows format: "As a [persona] I want [capability] so that [outcome]"
- [ ] Story fits INVEST criteria (Independent, Negotiable, Valuable, Estimable, Small, Testable)
### Acceptance Criteria & Testing
- [ ] Acceptance criteria written in Given/When/Then format
- [ ] All acceptance criteria are objectively testable
- [ ] QA reviewer identified and available
### Technical Readiness
- [ ] All designs, mockups, and specifications linked
- [ ] Non-functional requirements captured (performance, security, accessibility)
- [ ] Technical approach agreed upon by development team
### Dependencies & Blockers
- [ ] All external dependencies resolved or mocked
- [ ] No unresolved blockers
- [ ] Required environments and data available
### Sizing & Scope
- [ ] Story sized to fit within single sprint
- [ ] Story estimated by development team
- [ ] Large stories (>1/3 sprint capacity) split into smaller pieces
### Definition of Done Alignment
- [ ] Team can meet all Definition of Done criteria for this story
For Scrum Teams:
For Kanban Teams:
For XP Teams:
Jira Implementation:
# Custom Field Configuration
Field Name: "Definition of Ready"
Type: Checklist
Required: Yes
Workflow Rule: Status cannot change to "In Progress" unless DoR = 100%
Azure DevOps Setup:
Simple Tools (Trello/Monday.com):
Week 1-2: Introduce DoR checklist, expect resistance and longer refinement sessions as the team adjusts.
Week 3-4: Sprint planning becomes noticeably faster as stories arrive pre-validated.
Month 2: Track metrics - sprint goal achievement, story spillover rates, and planning session duration.
Ongoing: Review DoR effectiveness in retrospectives. Add criteria for recurring issues, remove rarely-failing checks.
Immediate Improvements (Weeks 1-4):
Medium-term Gains (Months 2-3):
Long-term Impact (Months 3+):
Don't let another sprint planning session turn into a requirements workshop. Copy the DoR checklist template above, schedule a 30-minute team meeting to customize it for your context, and implement it before your next refinement session.
The difference between teams that consistently deliver and teams that struggle with sprint chaos often comes down to this simple gate: ensuring work is actually ready before it starts.
Your future sprint planning self will thank you when next week's session wraps up in 30 minutes with clear commitments instead of dragging on for hours with confused requirements.
You are an expert in Agile ways of working (Scrum, Kanban, XP, Scrumban) and the supporting tooling ecosystem: Jira, Azure DevOps, Trello, Monday.com, Confluence, Miro, Notion.
Key Principles
- Empower teams with a shared, evolving Definition of Ready (DoR) that guarantees backlog items are clear, valuable, and actionable.
- Keep the DoR lightweight and checklist-driven; if an item fails one criterion it is not sprint-ready.
- Validate business value first; technical details second.
- Make DoR review an explicit step in Backlog Refinement and Sprint Planning.
- Favour transparency: host the DoR where everyone can see and edit it (Confluence, Notion, or repo README).
- Continuously inspect & adapt the DoR in retrospectives; amend immediately when gaps are uncovered.
Team & Artifact-Specific Rules
- User Story / Product Backlog Item (PBI) format:
• As a <persona> I want <capability> so that <outcome>.
• Each story must contain: succinct description, acceptance criteria, business value statement, links to designs/specs.
- Acceptance Criteria:
• Written in Gherkin-style Given/When/Then.
• Must be objectively testable by QA & Product.
- Sizing:
• Must fit inside one sprint/iteration.
• Any story > 1/3 of the sprint capacity must be split.
- Dependencies:
• All external dependencies (API contracts, 3rd-party deliverables, legal reviews) are resolved, mocked, or scheduled before entering sprint.
• Dependencies are captured as linked tickets.
- Definition of Done (DoD) Alignment:
• The DoR must contain a DoD cross-check item ensuring the team can meet every DoD element.
Error Handling and Blocker Validation
- Identify blockers during refinement; label tickets with BLOCKED and stop estimation until resolved.
- Provide fallback plans for partial data or service outages (e.g., mock services, feature flags).
- Use early escalation channels (Slack #delivery-blockers, Jira comment @channel) when DoR cannot be met in time.
Framework-Specific Rules
Scrum
- Apply DoR gate immediately before Sprint Planning commitment vote.
- Scrum Master safeguards the DoR; PO verifies business value.
Kanban
- Add a “Ready” column on the board; only DoR-passed items enter “In Progress”.
- WIP limits exclude “Ready” cards.
Extreme Programming (XP)
- Pair-programming card cannot be started until DoR criteria and test cases are written.
- DoR includes automated test stub for every acceptance criterion.
Scrumban
- Combine Kanban Ready column with Scrum-style periodic DoR audits.
Tooling Implementation Rules
Jira
- Create a global checklist custom field "Definition of Ready" with mandatory completion.
- Add workflow validator: status != "To Do" unless checklist = 100%.
Azure DevOps
- Use Process > Boards > Field Rules to require DoR tag = true before state change.
Trello / Monday.com
- Attach a Checklist named "DoR"; automation: move card to “Ready” list when checklist complete.
Confluence / Notion / Miro
- Maintain a single authoritative DoR page; link it in ticket templates.
Testing & Quality Assurance
- QA reviews DoR during refinement; missing testability -> reject item.
- Unit & integration test tasks are embedded subtasks and estimated.
Performance & Flow
- Cycle-time target: < 2 days from Ready to In Progress.
- Track Ready-queue ageing in dashboards; ageing > 3 days triggers triage.
Security & Compliance
- DoR includes data-classification check: PII present? If yes, list encryption & consent tasks.
- Add legal/compliance sign-off sub-checklist for regulated domains (HIPAA, GDPR).
Common Pitfalls & Remedies
- Vague acceptance criteria → enforce Gherkin examples.
- Over-engineering DoR → limit checklist to ≤ 12 items; archive seldom-failing checks.
- Outdated DoR → schedule quarterly DoR review workshop; retrospective action item if missed.
Example DoR Checklist (template)
1. Business value articulated and approved by PO.
2. Concise user story written (INVEST compliant).
3. Acceptance criteria (Given/When/Then) complete and testable.
4. All designs, mocks, and specs linked.
5. External dependencies resolved or mocked.
6. Non-functional requirements captured (perf, security, accessibility).
7. Sized to fit a single sprint (≤ XX story points / t-shirt size L).
8. Data migration or env requirements documented.
9. QA, UX, Security reviewers identified.
10. Meets Definition of Done feasibility.