Definition of Ready

Clear criteria that ensure user stories are sufficiently detailed and prepared before being committed to a sprint.

Overview

The Definition of Ready (DoR) is a checklist that ensures user stories are well-defined, estimated, and ready for development before they enter a sprint. It prevents teams from starting work on poorly understood or incomplete requirements.

Purpose

DoR reduces mid-sprint discovery, prevents scope creep, and improves sprint predictability.

Core Principles

Clarity: Everyone understands what needs to be built
Completeness: All necessary information is available
Estimation: Team can reasonably estimate effort
Testability: Clear success criteria exist
Value: Business value is understood

Universal Definition of Ready

These criteria apply to all user stories before they can be pulled into a sprint.

1. User Story Format

Follows standard template

As a <user persona>
I want <goal/desire>
So that <benefit/value>

Written from user perspective
- Describes user need, not technical implementation
- Focuses on "what" and "why", not "how"
- User persona is specific (e.g., "bank customer", "payment operator")

Good Example:

As a bank customer
I want to view my recent payment transactions
So that I can track my spending and verify payments

Bad Example:

As a developer
I want to create a GET endpoint for payments
So that we can query the database

2. Acceptance Criteria

Acceptance criteria clearly defined
- Specific, measurable, testable criteria
- Cover happy path and edge cases
- Written in Given-When-Then format (where appropriate)
Success metrics identified
- How will we know it's successful?
- What metrics will we track?

Example Acceptance Criteria:

**Given** I am a logged-in bank customer
**When** I navigate to the payment history page
**Then** I see my 10 most recent payments

**And** each payment shows:
- Payment date
- Recipient name
- Amount
- Status (completed, pending, failed)

**Given** I have no payment history
**When** I navigate to the payment history page
**Then** I see a message "No payments found"

3. Dependencies Identified

Technical dependencies documented
- APIs that need to exist
- Database changes required
- External service integrations
Team dependencies identified
- Work blocked by other teams
- Shared resources needed
- Cross-team coordination required
Dependencies resolved or plan exists
- Blocking items completed OR
- Dependencies scheduled to complete before this story OR
- Clear plan to resolve during sprint

4. Estimated

Story estimated by the team
- Team has discussed and pointed the story
- Estimation done using team's preferred method (story points, t-shirt sizes)
- Estimate reflects team's confidence in understanding
Story is appropriately sized
- Can be completed within a sprint
- Ideally 1-5 story points (or small/medium)
- If larger, broken down into smaller stories
Complexity and unknowns identified
- Technical challenges flagged
- Areas of uncertainty documented
- Spikes completed if needed

5. Testable

Clear test scenarios identified
- Happy path test cases
- Edge case test cases
- Error scenario test cases
Test data requirements known
- What test data is needed?
- Is test data available?
- Can we create/mock test data?
Testing approach agreed
- Unit testing strategy clear
- Integration testing strategy clear
- Manual testing scope defined

6. Business Value

Business value articulated
- Why is this important?
- What problem does it solve?
- What's the business impact?
Priority clear
- Ranked against other stories in backlog
- Urgency understood
- Business deadline known (if applicable)
Definition of Done understood
- Team knows what "done" means for this story
- Any story-specific DoD criteria identified

7. Design and UX

UI/UX design available (if user-facing)
- Wireframes or mockups provided
- Design approved by stakeholders
- Responsive design considerations addressed
API contract defined (if backend)
- Request/response formats specified
- Error codes documented
- API versioning considered
Technical approach discussed
- Team has high-level implementation plan
- Architecture reviewed if complex
- Technical decisions made (libraries, patterns, etc.)

8. Compliance and Security

Security considerations identified
- Authentication/authorization requirements clear
- Data sensitivity classified
- OWASP Top 10 reviewed
Compliance requirements documented
- Regulatory requirements identified (PCI-DSS, GDPR, etc.)
- Audit logging requirements clear
- Data retention policies understood

9. Non-Functional Requirements

Performance requirements defined
- Response time expectations (e.g., API <500ms)
- Load requirements (e.g., 1000 concurrent users)
- Scalability needs
Availability requirements clear
- Uptime expectations (e.g., 99.9%)
- Maintenance window allowed?
- Disaster recovery needs
Accessibility requirements (if UI)
- WCAG level target (A, AA, AAA)
- Screen reader support needed
- Keyboard navigation required

Feature-Specific Definition of Ready

Additional criteria based on the type of work.

Backend API Stories

OpenAPI specification drafted
- Endpoint path defined
- Request/response schemas defined
- Error responses documented
Data model identified
- Database tables/collections needed
- Relationships defined
- Migration strategy clear
Integration points identified
- External APIs to call
- Message queues involved
- Third-party services needed

Frontend Stories

Design assets available
- Mockups for all screens/states
- Design tokens/style guide provided
- Icons and images available
API contract defined
- Backend APIs available or mocked
- Request/response formats known
- Error handling approach agreed
Browser/device support clear
- Supported browsers listed
- Mobile/tablet requirements defined
- Progressive enhancement strategy

Database Stories

Schema changes documented
- DDL scripts drafted
- Migration plan defined
- Rollback plan documented
Data migration plan
- Existing data transformation defined
- Data validation approach
- Downtime requirements
Performance impact assessed
- Query performance considered
- Index strategy defined
- Data volume estimated

Mobile Stories

Platform-specific requirements
- iOS requirements clear
- Android requirements clear
- Platform differences documented
Native vs cross-platform decision made
- React Native or native implementation?
- Justification documented
App store requirements
- Privacy policy implications
- Permissions needed
- App store guidelines reviewed

High-Compliance System-Specific DoR

Additional criteria for highly regulated systems or those handling sensitive data.

Critical Transaction Handling

Transaction integrity requirements
- Idempotency requirements clear
- Rollback/compensation scenarios defined
- Reconciliation approach documented
Audit requirements defined
- What data must be logged?
- Log retention period
- Audit trail immutability ensured
Fraud/Abuse prevention considered
- Risk scoring requirements
- Anomaly detection needs
- Rate limiting needs

Compliance and Regulatory

Regulatory requirements identified
- Industry-specific compliance (where applicable)
- Data privacy requirements (GDPR, CCPA, etc.)
- Industry regulations understood
- Security controls (SOC2, ISO 27001, etc.)
Data classification done
- Sensitive data identified
- Encryption requirements
- Data residency requirements

High Availability

SLA requirements clear
- Uptime targets (e.g., 99.95%)
- Recovery time objective (RTO)
- Recovery point objective (RPO)
Resilience requirements
- Retry/timeout strategies
- Circuit breaker needs
- Graceful degradation approach

Definition of Ready Checklist

Quick Checklist for Product Owners

## Story Definition

- [ ] User story follows template (As a... I want... So that...)
- [ ] Written from user perspective
- [ ] Business value clear

## Acceptance Criteria

- [ ] Acceptance criteria defined
- [ ] Criteria are testable
- [ ] Success metrics identified
- [ ] Edge cases covered

## Dependencies

- [ ] Technical dependencies identified
- [ ] Team dependencies identified
- [ ] Dependencies resolved or scheduled

## Estimation

- [ ] Story estimated by team
- [ ] Story is appropriately sized (<1 sprint)
- [ ] Unknowns identified

## Design

- [ ] UI/UX designs available (if applicable)
- [ ] API contract defined (if applicable)
- [ ] Technical approach discussed

## Compliance

- [ ] Security requirements clear
- [ ] Compliance requirements documented
- [ ] Performance requirements defined

## Ready for Sprint

- [ ] Product Owner approves story
- [ ] Team confident they can deliver
- [ ] All DoR criteria met

The INVEST Principle

Use INVEST to evaluate story quality:

Criteria	Description	Example
Independent	Can be developed independently	Not blocked by other stories
Negotiable	Details can be discussed	Solution approach flexible
Valuable	Delivers value to users	Clear business benefit
Estimable	Team can estimate effort	Well-understood scope
Small	Can be completed in a sprint	1-5 story points
Testable	Clear success criteria	Acceptance criteria defined

INVEST Check

Before sprint planning, verify each story meets all INVEST criteria.

When DoR is Not Met

Options

Refine the story - Work with Product Owner to complete missing items
Schedule a spike - Create research/investigation story to resolve unknowns
Defer to next sprint - Move to backlog if not ready
Split the story - Break into smaller, ready pieces

Don't Start Unready Work

Starting work on stories that don't meet DoR leads to:

Mid-sprint scope changes
Missed commitments
Frustration and rework
Reduced team velocity

Emergency Exceptions

Rare exceptions for:

Production incidents
Critical security vulnerabilities
Regulatory deadlines

Exception process:

Tech Lead and Product Owner explicit approval
Document what DoR items are missing
Timebox investigation (e.g., 4 hours)
Re-evaluate if still not ready

DoR is primarily enforced during backlog refinement sessions.

Weekly: 1-2 hour refinement session
Timing: Mid-sprint (allows refinement before next planning)
Attendees: Product Owner, Tech Lead, 2-3 developers

Review upcoming stories (top of backlog)
Clarify requirements (ask questions)
Identify dependencies (technical, team, data)
Draft acceptance criteria (with Product Owner)
Discuss technical approach (high-level)
Estimate stories (planning poker)
Mark stories as ready (if DoR met)

2-3 sprints worth of ready stories
Acceptance criteria refined
Dependencies identified/resolved
Stories estimated and prioritized

Refinement Goal

Aim to have 1.5-2x sprint capacity of ready stories before sprint planning.

Sprint Planning and DoR

Sprint Planning Meeting

Step 1: Review ready stories

Only consider stories that meet DoR
Confirm stories are still prioritized correctly
Verify dependencies are still resolved

Step 2: Commitment

Team pulls stories into sprint based on capacity
Only pull ready stories
Leave buffer for unplanned work (bugs, support)

Step 3: Decompose into tasks

Break stories into technical tasks
Identify task owners
Confirm sprint goal

Red Flags During Planning

Stories without acceptance criteria
Stories with unresolved dependencies
Stories the team doesn't understand
Stories estimated as "too large"
Stories with no design/API contract

Action: Move these back to backlog for refinement.

Examples

Example 1: Ready Story

**Story**: View Recent Payments

**As a** bank customer
**I want to** view my recent payment transactions
**So that** I can track my spending and verify payments

**Acceptance Criteria**:

1. **Given** I am logged in
   **When** I click "Payment History" in the navigation
   **Then** I see my 10 most recent payments

2. **And** each payment displays:
   - Payment date (format: DD/MM/YYYY)
   - Recipient name
   - Amount (format: $X,XXX.XX)
   - Status: Completed, Pending, or Failed

3. **Given** I have more than 10 payments
   **When** I scroll to the bottom of the list
   **Then** I see a "Load More" button

4. **Given** I have no payment history
   **When** I navigate to Payment History
   **Then** I see "No payments found. Make your first payment to see it here."

**Dependencies**:
-  [GOOD] Payment API endpoint exists (GET /api/payments)
-  [GOOD] User authentication working

**Design**:
- Figma mockup
- Mobile responsive design included

**Technical Notes**:
- Use pagination (10 items per page)
- Cache results for 5 minutes
- Show loading skeleton while fetching

**Security**:
- Users can only see their own payments (verified by auth token)
- No sensitive data in logs

**Performance**:
- API response <500ms (P95)
- Frontend render <200ms

**Estimate**: 3 story points

**Definition of Done**: Standard team DoD applies

GOOD:  **Ready for Sprint**

Example 2: Not Ready Story

**Story**: Improve payment performance

**As a** user
**I want** payments to be faster
**So that** it's more convenient

BAD:  **Not Ready - Issues**:

1.  [BAD] Vague user persona ("user" - which user?)
2.  [BAD] No specific acceptance criteria (how much faster?)
3.  [BAD] No current baseline (what's current performance?)
4.  Not testable (how do we verify success?)
5.  [BAD] No business value articulated (why is this important?)
6.  [BAD] Cannot be estimated (too vague)

**Refinement Needed**:
- Define current performance baseline
- Set specific performance targets
- Identify which payment flows to optimize
- Create spike to investigate bottlenecks
- May need to split into multiple stories

Example 3: Spike Story (To Make Other Stories Ready)

**Spike**: Investigate Payment Retry Implementation Options

**As a** development team
**We want to** research retry mechanism options for failed payments
**So that** we can make informed decisions for future payment retry stories

**Acceptance Criteria**:

1. Research 3 retry approaches:
   - Spring Retry
   - Resilience4j
   - Custom implementation

2. Document for each approach:
   - Setup complexity
   - Configuration options
   - Monitoring/observability
   - Team familiarity

3. Provide recommendation with justification

**Timebox**: 4 hours

**Output**: Technical design document in Confluence

**Estimate**: 2 story points

**Follow-up**: Creates ready stories for payment retry implementation

Comparison: Definition of Ready vs. Definition of Done

Definition of Ready (DoR)	Definition of Done (DoD)
Before sprint planning	After development
Criteria for Product Owner	Criteria for Development Team
Ensures story can be started	Ensures story can be released
Focuses on clarity and planning	Focuses on quality and completeness
Checked in refinement	Checked before demo/release
Prevents starting poorly defined work	Prevents releasing incomplete work

Both are essential for predictable, high-quality delivery.

Evolving the Definition of Ready

When to Update DoR

Team frequently discovers missing information mid-sprint
New types of work require additional criteria
Compliance/regulatory requirements change
Team matures and needs more/less detail

How to Update DoR

Discuss in retrospective
Identify patterns of "unready" stories
Propose additions to DoR
Reach team consensus
Update this document
Communicate to Product Owner

DoR Review Cadence

Quarterly: Comprehensive review
After retrospectives: If refinement issues raised
New team members: Ensure understanding
Process changes: Update as needed

Summary

Key Takeaways:

DoR prevents starting unready work - saves time and frustration
All criteria must be met before pulling stories into sprint
Backlog refinement is where DoR is enforced
Product Owner responsibility to ensure stories meet DoR
Team responsibility to not pull unready stories
INVEST principle helps evaluate story quality
Spikes are used to make complex stories ready
DoR and DoD work together for predictable delivery

Critical Systems

For systems handling sensitive data or critical operations, DoR is essential for:

Identifying compliance requirements early
Understanding security implications upfront
Preventing mid-sprint discovery of audit requirements
Ensuring performance and availability targets are clear

Never skip DoR for security-sensitive or business-critical stories.

Overview​

Core Principles​

Universal Definition of Ready​

1. User Story Format​

2. Acceptance Criteria​

3. Dependencies Identified​

4. Estimated​

5. Testable​

6. Business Value​

7. Design and UX​

8. Compliance and Security​

9. Non-Functional Requirements​

Feature-Specific Definition of Ready​

Backend API Stories​

Frontend Stories​

Database Stories​

Mobile Stories​

High-Compliance System-Specific DoR​

Critical Transaction Handling​

Compliance and Regulatory​

High Availability​

Definition of Ready Checklist​

Quick Checklist for Product Owners​

The INVEST Principle​

When DoR is Not Met​

Options​

Emergency Exceptions​

Backlog Refinement Process​

Refinement Cadence​

Refinement Agenda​

Refinement Output​

Sprint Planning and DoR​

Sprint Planning Meeting​

Red Flags During Planning​

Examples​

Example 1: Ready Story​

Example 2: Not Ready Story​

Example 3: Spike Story (To Make Other Stories Ready)​

Comparison: Definition of Ready vs. Definition of Done​

Evolving the Definition of Ready​

When to Update DoR​

How to Update DoR​

DoR Review Cadence​

Further Reading​

Summary​