Definition of Ready

Ready means the conversation happened before the sprint, while it was still cheap.

The most common way work goes wrong is someone picking up a ticket whose backend, interface or data model doesn’t exist yet, or hasn’t been properly thought through for the task. A definition of ready is a short checklist that catches that before anyone starts.

The checklist

• Why: the user and the value are stated, and you can explain the ticket in one sentence.
• What: acceptance criteria written as concrete examples, including at least one unhappy path.
• Contract: the API, event or schema is agreed by both ends, or the ticket’s job is agreeing it.
• Design: a mock-up exists for anything visual, and the people building the UI have seen it.
• Dependencies: other teams, endpoints, data and access are identified and written down.
• Small: it fits in a sprint; otherwise split it into thin vertical slices (INVEST).
• Unknowns: if nobody can estimate it, the first ticket is a time-boxed spike.

Why it’s worth the friction

When there’s pressure to start new work, planning feels like overhead. But every gap on this list gets discovered eventually, mid-sprint, when it’s expensive: blocked work, rework and context switching. Ready pulls that discovery forward to the cheapest moment. The longer version, from statement of work through to done, is in From Statement of Work to Done: Requirements Both Ends Can Build From.

The AI angle

A ready ticket is also an agent-ready ticket. Examples, an agreed contract, known dependencies and a small scope are exactly what a coding agent needs to produce something useful instead of a confident guess. Teams that invest in ready tickets get more out of AI, not less.

Its counterpart at the other end of the ticket is Definition of Done.