Description
Open the item at the top of your backlog and read it as somebody who has never met your team. No domain knowledge. No colleague to ask. Judged only on whether the code does what the item says. That is exactly the position an agent is in every time it picks one up. If you would want to ask a question, so does it. The difference is that you would ask.
It does not ask. Given something ambiguous it picks an interpretation, writes fluent code against that interpretation, generates tests that pass against it, and opens a clean pull request. Nothing in the change announces that a decision was made. The reviewer sees working code and reasonable tests, because from inside the interpretation everything is consistent. Weeks later, support takes a call from the customer who found the gap.
This is not a story about sloppy teams. When experienced developers were asked to screen real issues from active open source projects, written by other working developers, a large share were judged too underspecified to fairly evaluate any implementation against, and the benchmark had to be filtered heavily before anybody would publish it. Backlog items have always been written as prompts for a conversation, because the next step in the workflow was a person who would push back when something did not add up.
The agent is not that person. It is closer to a compiler, and a compiler does not query intent. So the thing worth scoring is not whether your items are neatly formatted, it is whether the goal, the preconditions, what done means and the edge cases are decided before the work is pulled rather than during it, and whether anything checks that before an agent is handed the ticket.
The five levels
One question decides which rung you are on: does the system itself act on this, or does a human have to choose to? Each rung carries a tell: the thing that would settle it, so the score is something you checked rather than something you agreed with.
- 1
Blind
Backlog items are a title and a sentence of context. What finished means lives in a conversation that has not happened yet, and the person who wrote the item and the person who will build it each assume the other holds the detail. An agent handed this does not stop to ask, because asking is not what it is optimised to do. It assumes, and it assumes confidently.
The tellTake the top item in your backlog and read only what is written in it. If you cannot say what would have to be true for it to be done, neither can whoever picks it up next.
- 2
Tacit
Some items are excellent, because some people write them that way. Quality tracks the author rather than the process. One team has a product owner who writes testable briefs; two columns over on the same board, the items are a single line each, and nothing treats those differently when they are pulled.
The tellRead the top five items written by three different authors. If you can tell who wrote which from the level of detail alone, your standard is a person.
- 3
Visible but inert
There is a template and a definition of ready. It names the goal, the preconditions, the acceptance criteria and the edge cases, and it is genuinely good. Items that ignore it get picked up anyway, because the sprint is starting and the template is guidance. It describes how the process is meant to feel rather than what the backlog contains.
The tellCount how many of the last ten items pulled into work met your own definition of ready at the moment they were pulled. If the answer were a good one, you would already know it without counting.
- 4
Acted on
An item cannot be picked up until it is a testable spec. The check runs before work starts and it is not a preference: goal, preconditions, acceptance criteria and the edge cases that matter are present, or the item does not move. The argument about whether something is ready happens at the beginning, where it is still cheap.
The tellTake the last five items pulled into work and find the readiness check on each one. Here every check ran before the pull, and you can point at the item that was sent back.
- 5
Durable
The specification stays true after the work starts. When acceptance criteria change, the change reaches whoever is building against them, including an agent that read the item this morning. Ambiguity discovered during implementation goes back into the item rather than into someone's memory, and the standard survives a quarter when everybody is behind.
The tellFind an item whose requirement changed while it was being built. Check whether the item was updated before the code was, or only after the demo went wrong.
What this dimension rests on
The five levels are observed, from client engagements, and no paper produced them. What the research below establishes is why this dimension is worth scoring at all. No links: the citations carry enough to find them, and they stay findable after a link would have rotted.
Wu et al., ClarifyCoder: Clarification-Aware Fine-Tuning for Programmatic Problem Solving (2025)
Measured what code models do when a prompt is ambiguous, and found that most of the time they generate code rather than ask. Assuming is the default, not the exception.
Li, Wu and Chang, ClarEval: A Benchmark for Evaluating Clarification Skills of Code Agents (2026)
Injected ambiguity into otherwise solvable tasks and watched pass rates collapse on the same model and the same problem. The precision of the brief, not the model, was the dominant variable.
Where this came from
This dimension has a published article behind it, written from client engagements rather than from a greenfield repository.
Read the article on Requirements quality →
How to climb this dimension is not written yet. It is the next thing this page grows, and saying so is more useful than a paragraph of generic advice.