What is the difference between Definition of Ready and Definition of Done?

The Definition of Ready defines when a story is clear enough to start working on. The [Definition of Done](/templates/definition-of-done-template) defines when a story is complete enough to ship. Ready is the entry gate. Done is the exit gate. Both are team agreements that reduce ambiguity.

Should every story pass the full DoR checklist?

Not necessarily. Bug fixes and technical spikes may skip design requirements. The core items (clear acceptance criteria, estimation, no blocking dependencies) should apply to every story. Create lightweight variants for non-standard work.

Who is responsible for making stories ready?

The [product manager](/glossary/associate-product-manager) owns story clarity, acceptance criteria, and business context. The designer owns mockups and interaction specs. Engineering contributes to technical approach and estimation. Readiness is a shared responsibility, not one person's job.

How do we handle urgent stories that are not ready?

If a critical bug or business emergency requires pulling an unready story into the sprint, do it. Document what is missing and accept the risk of mid-sprint clarification. But track these exceptions. If "urgent unready stories" happen every sprint, the real problem is planning discipline, not emergencies.

Does the DoR slow down delivery?

In the short term, it adds friction to refinement. In the medium term, it reduces mid-sprint churn, carry-overs, and rework. Teams that adopt a DoR typically see [velocity](/glossary/velocity) stabilize within 3-4 sprints because they stop starting work they cannot finish. The [Scrum vs. Kanban comparison](/compare/scrum-vs-kanban) discusses how both frameworks handle work-in-progress limits.

Definition of Ready Template

What This Template Is For

A Definition of Ready (DoR) is the team's checklist for deciding whether a user story is clear enough to pull into a sprint. Stories that enter a sprint without clear acceptance criteria, designs, or dependency resolution cause mid-sprint chaos: engineers ask clarifying questions, scope creeps, and the story carries over to the next sprint.

This template defines the minimum bar a story must meet before the team commits to it during sprint planning. It pairs directly with the Definition of Done template, which covers the exit criteria. Together they bookend the story lifecycle. For teams building their agile practices, the guide to running sprint planning explains how to use both definitions in practice.

When to Use This Template

When stories frequently carry over: Unfinished stories often trace back to unclear requirements at sprint start.
During backlog refinement: Use the DoR as a checklist to decide whether a story is ready.
New team kickoff: Set expectations for story quality from day one.
When engineers complain about unclear stories: A DoR shifts the burden of clarity from sprint planning to refinement.

Step-by-Step Instructions

Step 1: Define Your Ready Criteria (15 minutes)

Start with the template below. Remove items that do not apply and add any team-specific requirements (e.g., legal review, data privacy assessment).

☐ Review each category (clarity, design, technical, dependencies)
☐ Remove items that do not fit your team's workflow
☐ Add team-specific criteria
☐ Get agreement from both product and engineering

Step 2: Integrate into Backlog Refinement (Ongoing)

Use the DoR during your weekly refinement session to evaluate each candidate story.

☐ Product manager presents each story
☐ Team evaluates against the DoR checklist
☐ Stories that pass move to "Ready" status
☐ Stories that fail get tagged with what is missing

Step 3: Enforce During Sprint Planning

During sprint planning, only pull stories from the "Ready" column. If a high-priority story is not ready, refine it live or defer it.

☐ Only pull "Ready" stories into the sprint
☐ Track how many stories fail the DoR check each sprint
☐ Adjust the DoR if it is too strict or too loose

The Definition of Ready Template

Story Clarity

☐ User story follows the format: "As a [user], I want [action] so that [outcome]"
☐ Acceptance criteria are written and specific (not vague "works correctly")
☐ Business value or user outcome is stated
☐ Story is small enough to complete in one sprint
☐ Edge cases and error states are described

Design and UX

☐ Mockups or wireframes attached (for UI stories)
☐ Design reviewed and approved by designer
☐ Interaction states defined (loading, empty, error, success)
☐ Mobile responsiveness requirements specified (if applicable)

Technical Clarity

☐ Technical approach discussed with engineering
☐ API contracts or data models defined (if applicable)
☐ Performance requirements specified (if applicable)
☐ No open technical questions blocking implementation

Dependencies

☐ External dependencies identified and resolved (or plan documented)
☐ Other team dependencies communicated and scheduled
☐ Third-party integrations tested in sandbox (if applicable)
☐ Data migration plan documented (if applicable)

Estimation

☐ Story is estimated in story points or t-shirt sizes
☐ Estimate reflects the full DoD (code, tests, docs, deployment)
☐ Team consensus on the estimate (not just one person's guess)

Example

Here is a filled-in DoR evaluation for a story entering Sprint 18.

Story: As a billing admin, I want to download invoices as PDF so that I can share them with our finance team.