Why this matters: most of our sprint failures were decided before the sprint started, at the moment we pulled in a Story nobody fully understood. This is the gate that prevents that, and we currently do not have one. See Why We Miss Deadlines.
What it is
The Definition of Ready is a short checklist a Story must pass before it is allowed into a sprint.
It answers one question:
Do we understand this well enough to responsibly start building it?
That is all. It is not a quality standard for finished work, that is Definition of Done. It is a filter on the way in.
One honest disclaimer
Definition of Ready is not an official Scrum artifact. The Scrum Guide defines Definition of Done as a commitment, but for readiness it only says that backlog items which are sufficiently transparent and can be completed within a sprint are considered ready for Sprint Planning. The Agile Alliance describes DoR as a practice many teams adopt: criteria an item should satisfy before entering an iteration.
So this is a team practice, not a law, and that matters for how you use it. It is a conversation tool, not a bureaucratic weapon. If a Story misses one checklist item but everybody genuinely understands it, take it. If a Story ticks every box and the team still feels uneasy, do not take it, and find out why the checklist missed something.
The failure mode to avoid is DoR becoming a mini waterfall where a Story needs six documents and three signatures to start. That is worse than having no DoR at all.
A starter checklist
Keep it short. Seven items maximum. Mine would be:
- The business reason is clear. We can say why this matters, not just what it does.
- The Story is written as a small user or business outcome, at the right level per Work Breakdown Hierarchy.
- Acceptance Criteria are written, including the main error cases.
- Dependencies are identified. Other teams, external APIs, data migrations, third party approvals.
- Designs or mockups exist if the Story has a meaningful UI.
- The big unknowns have been investigated, or a spike has been done. If nobody can estimate it, it is not ready.
- The team has estimated it, and the size fits comfortably inside one sprint. See Estimation and Story Points.
If several of these are missing, the Story does not enter the sprint. It goes into refinement. That is not obstruction, it is the only thing that stops the team from committing to work it cannot possibly size.
How to use it without becoming a bureaucracy
Apply it during refinement, not at Sprint Planning. By the time you are in planning, discovering that a Story is not ready is already a small disaster, because now you either take it anyway (and fail) or you have a half empty sprint. Refinement is where readiness gets built. See Sprint Planning and Refinement.
Make it visible. In Azure DevOps this is simply a “Ready” tag or a board column, so anyone can see at a glance how much ready work exists. The mechanics are in Azure DevOps Setup.
Keep two sprints of ready work. Not more, not less. Less, and Sprint Planning becomes a scramble where you take whatever exists. More, and you are writing detailed criteria for work whose priority will change before you build it, which is pure waste.
Treat repeated misses as data. If half the backlog keeps failing DoR, the problem is not the checklist. It is that refinement is not happening, or that requirements are arriving from stakeholders as one line requests with nobody translating them.
The exception, and how to handle it honestly
Something urgent will always arrive that is not ready. A production issue, a regulator deadline, a demo for a large customer next Tuesday.
The correct response is not to pretend the checklist does not exist and not to refuse the work. It is to take it consciously and say out loud what you are accepting: “This has no acceptance criteria and we have not sized it. We are taking it anyway because of X. It might not finish, and if it grows we will drop Y from this sprint.”
That sentence costs nothing and it changes everything, because now the risk is shared rather than quietly transferred to the developers. The trade off mechanics are in Feedback and Scope Control and Velocity and Capacity.
The ready funnel
A healthy backlog is not uniformly detailed. It has a gradient:
flowchart TD
A["Next sprint<br/>small, clear, criteria written, estimated, READY"]
B["Sprint + 1<br/>mostly clear, criteria drafted, roughly sized"]
C["Sprint + 2<br/>understood at Story level, not detailed yet"]
D["Further out<br/>still Features and Epics, deliberately not analysed"]
A --> B
B --> C
C --> D
Spending a week writing acceptance criteria for something you may build in six months is waste, and worse, it produces a false sense of certainty. The Scrum Guide describes refinement as progressively adding detail: description, order, size. Progressively is the operative word.
What DoR does for your delivery
Look at the loop in Why We Miss Deadlines. Stories that were not ready are the ones that grow mid sprint, because everything that was never discussed arrives later as “feedback”. DoR does not eliminate that, but it moves most of the discovery from during the sprint, where it destroys the plan, to before the sprint, where it costs a conversation.
One number worth tracking: percentage of Stories that entered the sprint without acceptance criteria. If that number is high, no amount of better estimating will save your predictability.