> For clean Markdown of any page, append .md to the page URL.
> For a complete documentation index, see https://cla-demo.postmansolutions.com/llms.txt.
> For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://cla-demo.postmansolutions.com/_mcp/server.

# 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