What is a Definition of Ready for, and how can it starve a team of work?
answer
- An entry condition for starting work
- Clear enough to begin, small enough to finish
- A heuristic the team may waive
- Queues form upstream of a hard gate
basics
~20 sA Definition of Ready is the team's agreed entry checklist for starting a work item: clear enough to begin, small enough to finish. It starves a team when it hardens into a gate blocking work until somebody supplies perfect detail.
solid answer
~40 sA Definition of Ready is the team's own entry agreement, typically four or five checks: the outcome is stated, acceptance criteria are testable, no blocking dependency is open, it looks small enough for one iteration, and somebody can answer questions about it this week. It prevents one specific waste - pulling in an item and spending the first hours guessing what it means. It starves the team when checks accumulate after every incident, the list becomes a mandatory form, and one busy person becomes the judge. Work then queues upstream, where nobody measures it, and people sit idle beside nearly-ready items. Keep it short, let the team waive a check and report afterwards what the waiver cost, and measure how long an item waits before anyone is allowed to start it.
code
pseudocode · 11 linesREADY (team agreement, reviewed every few iterations)
- the outcome is stated: who wants it, and what changes for them
- acceptance criteria are testable and fit on one screen
- no unresolved blocking dependency on another team
- the team believes it fits inside one iteration
- someone can answer questions about it this week
WAIVER
any two developers may start an item that fails a check,
and report at the next planning session which check was
waived and what the waiver cost.go deeper
Know that readiness is an entry condition for starting an item - the outcome is clear, the criteria are testable, it looks small enough - and that it is the team's own agreement rather than a rule imposed on it.
Explain the tradeoff. Expect to describe what the checklist prevents, why it has to stay short and waivable, and how a growing mandatory list pushes work into a queue while people wait for permission to start.
Show that you would measure the gate. Talk about how much work sits waiting to be judged ready, how long it waits, and how you would relax or delete checks once idleness costs more than the occasional bad start.
Own the upstream system. A starvation gate is usually a symptom of who supplies work and how, so argue for changing that flow rather than tightening the checklist, and say what you would accept starting without.
## What readiness is trying to prevent A **Definition of Ready** is a short agreement about what must be true before a team starts a work item. It exists to prevent one specific waste: an item pulled in on Monday whose first hours go to working out what it means — chasing whoever wrote it, discovering that it depends on a service nobody has built, or finding that it is three items wearing one coat. The value is real and it is narrow. Readiness is an **entry condition**, checked before work begins. It is not a standard for finished work; that is a separate agreement with a separate purpose and a separate owner, and running the two together is the most common mistake made with the term. ## What a workable checklist contains Four or five checks, each phrased as something a developer can verify in under a minute: - The **outcome** is stated: who wants this, and what changes for them. - **Acceptance criteria** exist and are testable — you can say what would prove it works. - **No unresolved blocking dependency** on another team or an undelivered component. - The team believes it **fits inside one iteration**; if it does not, it is split first. - Someone who can **answer questions** about it is reachable this week. Notice what is deliberately absent: a full design, an estimate in hours, sign-off from anyone outside the team, every edge case enumerated. Those are the checks that turn readiness into paperwork. ## How it becomes a starvation gate The failure mode is gradual, and every individual step looks like an improvement. 1. Something goes wrong mid-iteration, so a check is added to stop it recurring. Nobody ever removes one. 2. The list outgrows what a conversation can carry, so it becomes a form, and the form becomes mandatory. 3. Mandatory means enforced, and enforcement needs a judge — usually one person, usually busy. 4. Work now queues in front of that judgement. The queue is invisible, because it sits upstream of everything the team measures. 5. People sit idle beside a pile of nearly-ready work, and the team concludes that it needs more refinement — which adds checks. | | Readiness as a heuristic | Readiness as a gate | |---|---|---| | Who applies it | The team, when pulling an item | An approver, before anyone may pull | | Number of checks | Four or five, and stable | Grows after every incident | | An item that fails | Prompts a five-minute conversation | Blocked until it is re-submitted | | Effect on flow | Fewer restarts mid-iteration | A queue upstream, and idle people | | Waiving a check | Normal, and reported afterwards | Requires a formal exception | A concrete case. A seven-person team building an allotment-management service let its readiness checklist grow to eleven entries in the months before a release timed to an annual conference. On the second day of one iteration, three of the seven had nothing they were permitted to start: the items existed, most of the detail was written, and each was waiting on one missing check. The team's delivery problem was neither capability nor capacity. It had built itself a queue and called it quality. ## Keeping it useful - **Keep it short.** Four or five checks. Adding a sixth should require removing one. - **Make it waivable by the team.** A useful convention: any two developers may start an item that fails a check, and say at the next planning session which check was waived and what the waiver cost. The feedback loop survives; the queue does not. - **Aim it at conversation, not compliance.** The checklist's job is to make somebody ask a question this afternoon, not to reject a submission. - **Measure the gate, not the meeting.** Count items waiting to be judged ready against items in progress, and measure how long a typical item waits before anyone is allowed to start it. If that wait is growing, the checklist has become the bottleneck. - **Prune it deliberately.** Once a quarter, ask of each check: when did this last catch something, and what did it cost us in waiting? ## When you do not need one at all A team working closely with whoever wants the software, on a product it knows well, often needs no written readiness agreement at all — the conversation happens naturally and a checklist would only formalise it. Readiness earns its place when the distance between the team and the requester is large enough that guessing gets expensive: several teams involved, a slow feedback loop, a requester in another time zone. If you cannot say which specific waste your checklist prevents, you are paying for a ritual rather than buying anything.
- Who owns a Definition of Ready, and can it be waived?The team that pulls the work owns it, and it must be waivable or it stops being a heuristic. A workable convention is that any two developers may start an item that fails a check, then say at the next planning session which check was waived and what it cost. That keeps the feedback the checklist was built for without creating a queue in front of it.
- How would you tell that readiness has become a starvation gate?Look upstream rather than at the meeting. Count items waiting to be judged ready against items in progress, and measure how long a typical item waits before anyone is permitted to start it. If people are idle beside a pile of nearly-ready work, the checklist is now the bottleneck, and the fix is to shorten it or make waiving it routine.
A readiness checklist should work like a smoke detector rather than a locked door: it makes you look before you walk in, but it does not stop you entering.
saying these in an interview costs you the question
- Treats the checklist as a contract against whoever writes items
- Confuses an entry condition with a standard for finished work
- Adds a check after every incident and never removes one
- Believes an item must be fully specified before work starts
- Leaves developers idle rather than starting anything imperfect