Definition
A Definition of Ready (DoR) is the set of conditions a user story or backlog item must satisfy before a team pulls it into a sprint. Think of it as a quality gate for incoming work. If a story lacks clear acceptance criteria, has unresolved dependencies, or is missing designs, it fails the DoR and stays in the backlog until it is properly prepared.
The concept comes from lean manufacturing's idea of "ready work stations" -- ensuring raw materials are staged before production begins. In software teams, the raw material is a well-defined story. Spotify's squad model famously enforced DoR at the squad level, requiring that every ticket entering a sprint had acceptance criteria, a technical approach, and confirmed designs. Teams that skipped this step saw 30-40% of sprint capacity lost to mid-sprint clarification.
Why It Matters for Product Managers
PMs own backlog quality. When a poorly defined story enters a sprint, engineers burn time asking clarifying questions, designers scramble to provide missing specs, and the story either balloons in scope or gets punted to the next sprint. A Scrum.org survey found that teams with a clear DoR completed 24% more story points per sprint than those without one.
The DoR also forces PMs to do their homework before sprint planning. Writing acceptance criteria, confirming technical feasibility with the tech lead, and attaching mockups are all PM responsibilities that happen before the sprint starts. Without a DoR, this work gets deferred into the sprint, turning engineers into detectives instead of builders.
A well-enforced DoR also reduces the "but what about..." conversations mid-sprint. When everyone agrees upfront that a story is ready, there is less room for scope disagreements later.
How It Works in Practice
Draft the checklist -- The PM and engineering lead co-create a DoR with 5-7 items. A typical list: acceptance criteria written, UX mocks linked, no unresolved blockers, story fits in one sprint, tech approach reviewed.
Review during refinement -- In backlog refinement (grooming), the team checks each candidate story against the DoR. Stories that fail stay in the backlog with a note about what is missing.
Gate sprint planning -- At sprint planning, the Scrum Master or tech lead verifies every story meets the DoR before the team commits. No exceptions. If a story is not ready, it does not enter the sprint.
Iterate quarterly -- Review the DoR every quarter. If the team keeps hitting the same problems (e.g., missing API contracts), add that item to the checklist. If an item never catches anything, remove it.
Common Pitfalls
Making the checklist too long. A 15-item DoR becomes bureaucratic. Teams stop checking it. Aim for 5-7 items that address your most frequent sprint disruptions.
Confusing DoR with Definition of Done. DoR gates the start of work; DoD gates the end. They complement each other but serve different purposes. A story that meets DoR criteria enters the sprint; a story that meets DoD criteria exits the sprint.
Treating DoR as optional under time pressure. The moment a PM says "just pull it in, I will clarify later," the DoR loses credibility. The whole point is that unready work costs more to fix mid-sprint than to prepare upfront.
Not involving engineers in defining the DoR. If only the PM decides what "ready" means, the checklist will miss technical readiness criteria like confirmed API availability or data migration plans.
Related Concepts
Definition of Done (DoD) is the exit counterpart to DoR -- it defines when work is complete rather than when it is ready to start.
Sprint Planning is the ceremony where the DoR gets enforced, since the team evaluates which stories are ready to commit to.
Backlog refinement is where most DoR preparation happens -- PMs use refinement sessions to get stories to a "ready" state before sprint planning.Explore More PM Terms
Browse our complete glossary of 100+ product management terms.