A definition of ready: when a backlog item may enter an iteration

What it is

A short checklist applied to a backlog item before the team takes it into an iteration. Typical entries: the item states who needs what and why; acceptance criteria exist and have been read by a developer; dependencies on other teams or decisions are resolved or explicitly excluded; the team has sized it and it fits in one iteration; test data or access needed is available. The Scrum Guide does not define a "Definition of Ready" as a formal artifact, but says that Product Backlog items that can be Done by the Scrum Team within one Sprint are deemed ready for selection, and that they usually reach that state through refinement. Bill Wake's INVEST list describes the qualities: independent, negotiable, valuable, estimable, small, testable.

Why it matters

Items that enter an iteration half-understood get blocked mid-way, are carried over, and distort every measure of throughput. A definition of ready moves the discovery of "we cannot actually do this yet" from the middle of the iteration to refinement, where it costs a conversation rather than a context switch.

How to apply

• Write the checklist with the developers, not for them; keep it to a handful of observable conditions.
• Apply it in refinement, out loud, one item at a time; an item that fails gets a note saying what is missing and who supplies it.
• Keep "negotiable" from INVEST in mind: ready means the intent and the examples are clear, not that every detail is specified.
• Track how often items are pulled in despite failing the list and how often those items are carried over; that pair of numbers tells you whether the list is doing anything.
• Revise the list when an item that passed still blocked; add the missing condition or accept that some unknowns only show up in the work.

Pitfalls

A definition of ready enforced as a stage gate recreates a hand-off between "analysis" and "development" and delays work while documents are perfected. Readiness applied to the whole backlog wastes refinement on items that may never be built; refine only the next iteration or two. A team that cannot get items to ready has an upstream problem (absent product owner, unresolved strategy) that the checklist exposes but does not solve.