Does a definition of ready help coding agents?
Stefan-Iulian Tesoi · · 6 min read
Yes, and a stricter one than most Scrum coaches recommend. The usual objection is that a ready gate turns refinement into a stage-gate, because with people a gap in an item gets resolved in conversation during the sprint. A coding agent does not ask. It fills the gap with a guess, so the gate is the last place that conversation can still happen.
A definition of ready is the test a backlog item must pass before anyone may start it. For a team whose builders are agents, it stops being a matter of taste.
What is a definition of ready?
A short list of conditions an item must meet before the team pulls it into work: the entry criteria, where the definition of done is the exit criteria. It is not in the Scrum Guide. The 2020 guide says only that items "that can be Done by the Scrum Team within one Sprint are deemed ready for selection in a Sprint Planning event", and that they "usually acquire this degree of transparency after refining activities."
Teams wrote their own lists to make that sentence testable, often starting from INVEST, Bill Wake's test that a story be Independent, Negotiable, Valuable, Estimable, Small and Testable. Typical ready for development criteria look like this:
- the user story is written;
- acceptance criteria exist;
- the item is estimated;
- dependencies are identified;
- designs are attached.
Why was a ready gate called an anti-pattern?
Because rules that demand everything be finished before work starts turn an iterative process back into a sequential one. Mike Cohn put it plainly in an article on its dangers: "If these rules include saying that something must be 100 percent finished before a story can be brought into an iteration, the definition of ready becomes a huge step towards a sequential, stage-gate approach."
His alternative was a guideline instead of a rule. Get an item "just far enough along that the team can resolve remaining open issues during the iteration." Analysis, design and coding then overlap, which is most of what agility means in practice.
For a human team the argument is sound. It also rests on one assumption: that someone in the iteration notices the open issue and asks about it.
Why does the objection fail when the reader is a coding agent?
Because nobody resolves the remaining open issues during the iteration. A coding agent working from an item does not walk over and ask which dashboard "the dashboard" means. It picks one. It does not ask whether the old endpoint has to keep working. It decides. Every gap becomes a guess, and a guess that compiles gets through most reviews.
With a person, a gap in the item is a question. With an agent, it is a decision nobody made.
The concurrent work Cohn defends depends on a conversation the agent never starts. So a gate is not a step back towards waterfall here. It is where the conversation moves: to before the item is pulled, between people, instead of during the build, between a person and a guess.
The fields-filled-in version of the gate does not help. Two P1 cards once sat on one board, titled "CI failing on main" and "Fix CI failures on main branch". Between them they named no repository, no workflow, no commit and no failing assertion. Both had a title, a description and a priority, so both would pass a ready check that only looks for those. Neither could be acted on without guessing. On the backlogs we have audited, between a third and a half of items pass a stricter test on the first attempt.
What belongs on a definition of ready checklist for agent work?
Tests the item's own text passes, answered without asking anyone. This definition of ready checklist is stricter than the human version in content and shorter in ceremony:
- The repository is named. Not "the frontend".
- The outcome is observable. What someone can do afterwards that they could not before.
- Every acceptance criterion can be run. Each names something to execute and something to observe.
- Scope is stated both ways. What may change, and the adjacent thing that must not.
- Dependencies are done, not listed. A blocker still in the backlog makes the item blocked, not ready.
- It is one change. Small enough to be built, reviewed and handed back as a unit.
- No question is open in the comments. An unanswered thread is a decision still pending.
The first five are the fields a backlog item an agent can execute cannot do without, and they close the defects described in a backlog an agent can actually read. Two items from the human list drop out. An estimate says nothing about whether an agent can act. An attached design counts only when the outcome names what it must match.
The definition of ready vs definition of done contrast is entry against exit:
| Ready | Done | |
|---|---|---|
| Checked | Before work is pulled | Before work is accepted |
| Tests | The item's text | The result and its evidence |
| In the Scrum Guide | No | Yes |
| Protects | The builder from guessing | Users from unfinished work |
| Failing it means | Back to refinement | Back to the builder |
The exit half for agent work is set out in a definition of done when an agent wrote the code.
Who decides an item is ready?
The person accountable for the backlog, not the agent that will build the item. Asked whether an item is ready, an agent will usually say yes, because it can always produce something. In Scrum terms the call belongs to whoever is accountable for "creating and clearly communicating Product Backlog items", which is the product owner.
In Laimonade, ready is a column rather than a label. An item in Ready is on the sprint and available to pull, and it is the column a connected coding agent reads, as the sprint workflow describes. The standard for arriving there is the one in the checklist: an item in Ready should need no further questions. Laimonade grooms items towards that standard continuously, so the check happens per item rather than once a week in a meeting.
Frequently asked questions
Is the definition of ready part of the Scrum Guide?
No. The 2020 Scrum Guide defines a Definition of Done and nothing equivalent for starting work. It says only that items which can be Done within one Sprint are "deemed ready for selection" at Sprint Planning, usually after refinement. A ready list is a team's own agreement for making that sentence something it can check.
How is it different from a definition of done?
A ready check happens before work starts and tests the item's text: can it be built without guessing? A definition of done is checked before work is accepted and tests the result: is it finished to the agreed standard? Ready protects the builder from ambiguity. Done protects users from unfinished work.
What happens to items that never pass?
They go back to refinement. An item that keeps failing is usually one of two problems: a decision nobody has made, or several items under one title. More wording fixes neither. Make the decision or split the item, and delete the ones nobody is willing to decide about.