What Is the Definition of Ready? How to Use It for Better Sprint Planning
The Definition of Ready (DoR) is a checklist of conditions that a backlog item must satisfy before it can be selected for inclusion in a sprint during sprint planning. While the Definition of Done defines when an item is complete, the Definition of Ready defines when it’s prepared to be worked on — ensuring that the team has everything they need to begin working on an item without encountering preventable blockers or wasting sprint planning time on items that aren’t ready.
Think of the Definition of Ready as the entry gate to the sprint, and the Definition of Done as the exit gate.
Why the Definition of Ready Matters
It Prevents Sprint Planning Waste
When items that don’t meet readiness criteria show up in sprint planning, the session stalls on questions that should have been answered beforehand: What does this actually mean? Who are the users? How do we know when it’s done? What are the dependencies? Resolving these questions in sprint planning wastes the team’s collective time and often produces less thoughtful answers than would have emerged from a dedicated backlog refinement conversation.
It Reduces Mid-Sprint Blockers
Items that weren’t ready when they entered the sprint often encounter blockers mid-sprint: the design wasn’t complete, a dependency wasn’t resolved, the acceptance criteria were ambiguous. The Definition of Ready catches these issues before the sprint begins, when they’re cheapest to resolve.
It Creates Accountability for Backlog Quality
The Definition of Ready gives the team a shared, explicit standard for backlog readiness — making it the product owner’s responsibility to ensure items meet the standard before bringing them to sprint planning, and giving the team a principled basis for declining items that don’t.
What a Definition of Ready Typically Includes
Every team’s DoR is different, but common elements include:
Description and user story: The item is clearly described in a format the team understands, with the user, goal, and rationale articulated.
Acceptance criteria: Clear, specific, testable criteria defining when the item is complete.
Size estimate: The item has been estimated by the team and is small enough to be completed in a single sprint. Items that exceed a certain size threshold should be decomposed first.
Dependencies identified: Any blocking dependencies have been identified. Ideally, blocking dependencies are resolved before the sprint begins, or at minimum, there’s a clear plan for resolving them quickly.
Design assets available: If the item requires design work, relevant mockups or specifications are available for engineering reference.
No blocking impediments: There are no known impediments that would prevent the team from beginning work on the item.
Applying the Definition of Ready
The DoR is applied during backlog grooming: items that don’t meet the readiness criteria are flagged for refinement before they move to the top of the backlog. This keeps sprint planning focused on selecting from items that are genuinely ready, rather than debating whether items can be worked on.
The product owner is primarily responsible for ensuring items meet the DoR before presenting them for sprint planning. Engineers and QA contribute by identifying what information they need to estimate and build effectively.
Definition of Ready vs. Definition of Done
These two definitions work as complementary gate mechanisms:
| Definition of Ready | Definition of Done | |
|---|---|---|
| When applied | Before the sprint (entry gate) | After work is complete (exit gate) |
| Purpose | Ensure the team can start the item | Ensure the item meets quality standards |
| Owner | Product Owner (primary) | Scrum Team (collective) |
| Focus | Backlog item quality | Increment quality |
Together, they create the bookend quality controls that keep sprint work well-defined on entry and well-executed on exit.
Key Takeaways
The Definition of Ready is a simple but powerful tool for improving sprint planning efficiency and reducing mid-sprint waste. By establishing a shared standard for backlog item readiness, it creates accountability for backlog quality, focuses sprint planning on actionable choices rather than information-gathering, and prevents the common problem of starting sprint work without the context and clarity needed to complete it well.