How to write a backlog item an agent can execute

Stefan-Iulian Tesoi · 19 August 2026 · 7 min read

Name the repository, state the observable outcome rather than the implementation, write acceptance criteria that can each be checked by running something, list the files or surfaces in scope, and resolve every dependency the item assumes already exists.

A backlog item for AI agents is not a better-written ticket. It is a ticket that survives having no author nearby, which is a different property and a harder one.

What does a backlog item for AI agents need?

Five fields, and a human reader never asks for any of them because a human reader can ask you instead.

That is the whole asymmetry. Writing user stories for AI agents feels like over-explaining, because the person writing is explaining things to themselves. Every field below is one someone on your team would find faintly insulting to read, and one an agent cannot proceed without.

Which five fields can an agent not infer?

1. Repository. The checkout, by name. Not "the frontend" — a team with four frontends has four answers to that.
2. Observable outcome. What a user can do afterwards that they could not before. Outcomes survive a rewrite; implementations do not.
3. Acceptance criteria that can be run. Three or four, each naming something to execute and something to observe.
4. Scope, both directions. The files or surfaces this item may touch, and the adjacent thing it must leave alone.
5. Dependencies, resolved. Not listed — resolved. An item that names a blocker still sitting in the backlog is not ready; it is a blocked item wearing a ready label.

Every one is cheap to write and expensive to omit, and omission does not produce an error. It produces confident, wrong work, which is worse than an error because it passes review.

Acceptance criteria that can be checked by running something

This is where most agent-ready acceptance criteria fall down, and the test is mechanical: can you name the command, and can you name the result?

The left column is not vague to a person. Everyone in the room knows what "search works" means. It is vague to anything that has to decide, unsupervised, whether it is finished — and that decision is the one you are delegating.

Work with no obvious test surface is the interesting case. A copy change has no API to call. The criterion is then the observation: "the pricing page's second heading reads X", which a person or a script can check in five seconds. A criterion you cannot write at all is a signal the item is not understood yet.

Before and after: one real item rewritten

The original, copied from a real backlog with the names changed:

Add a blog section so we can start publishing.

Everything about that is fine, and none of it is executable. Rewritten:

• Repository: marketing-site
• Outcome: A visitor can open /blog, see a list of posts newest first, and open one at /blog/<slug>.
• Criteria: /blog lists every markdown file in src/content/posts; each post renders its title, date and body; a post with malformed frontmatter fails the build rather than rendering blank; /blog/does-not-exist returns the 404 page.
• In scope: src/pages, src/content/posts, the route table.
• Not in scope: the RSS feed and the sitemap, which are their own item.
• Dependencies: none.

The rewrite took four minutes. The original version of this item, on a real team, produced a blog built in the wrong repository.

How do you tell an item is too large?

Three signals, in ascending order of certainty:

• The description contains the word "and" between two deliverables.
• The acceptance criteria cannot all be checked at the same moment, because some depend on later work.
• You cannot state the outcome in one sentence without a semicolon.

We split a thirteen-point story into six children once and the children came to twenty-six points. The estimate was not slightly optimistic — it was wrong by a factor of two, and nothing in the original item revealed that, because the missing work had never been written down to count.

What the item says about being finished

The five fields describe the work. One more thing has to be true before an agent can act on it: the item has to agree with your definition of done.

That sounds like process paperwork and is not. A definition of done that says "merged, reviewed and documented" is a statement about three artefacts, and an item whose criteria mention none of them is under-specified against your own standard. The mismatch is invisible while people are doing the work, because people know the house rules. An agent knows the item.

So the criteria and the definition of done have to name the same things:

• If done means tests pass, one criterion names the suite to run.
• If done means documentation is updated, one criterion names the page.
• If done means a person reviewed it, the item says what the reviewer is checking against — which is the criteria, written before the work started, not an impression formed afterwards.

This is where backlog grooming for coding agents diverges most from the version a human team runs. Grooming used to mean making items clear enough to discuss and estimate. It now means making them complete enough to execute and check, and those two bars are far apart. An item can be perfectly clear and still not say what finished looks like.

The practical consequence is cadence. Clear-enough-to-discuss is a weekly meeting's worth of work. Complete-enough-to-execute is continuous, because it has to happen to every item before it is dispatched rather than to a batch before a planning session.

A checklist to run before handing work to an agent

Four questions, answered from the item's text alone, no asking anyone:

1. Which repository?
2. What observable outcome?
3. What would prove it?
4. What must exist first, and is that sequenced before this?

Anything you cannot answer is the defect, and the item is where it lives. On the backlogs we have audited, the first pass rate is usually between a third and a half.

This is the per-item version of the argument in a backlog an agent can actually read, which covers the four defects these fields exist to close. The sprint workflow covers how items reach agents once they are ready, and connecting your coding agent covers the mechanics. Laimonade does this work continuously rather than at a weekly meeting, which is the only way it survives a busy sprint.

Worth reading alongside: INVEST, Bill Wake's twenty-year-old test for a good user story. Every letter still applies. What it does not ask — because in 2003 it did not need to — is whether a reader with no memory of the planning conversation could act on the item.

Frequently asked questions

How long should an agent-ready backlog item be?

Shorter than people expect, because the length comes from structure rather than prose. Five fields, three or four criteria, and no narrative — most of ours fit on a screen. An item running to several paragraphs of explanation is usually one that has not been decided yet, and the writing is the author thinking rather than specifying.

Should the item name the files to change?

Name the scope, not the solution. "This may touch src/pages and the route table" is useful: it bounds the change and stops two items claiming the same files. "Edit Blog.tsx line 40" is not, because it assumes an implementation that may be wrong, and an agent will follow it rather than question it.

What if the requirement genuinely is not known yet?

Then the item is not ready, and labelling it ready is the actual error. Write the question instead of guessing an answer: an item whose acceptance criterion is "decide whether posts are paginated, and record the decision" is honest, executable by a person, and unblocks the real item afterwards. Guessing produces work that has to be redone once somebody notices.

Who should write the criteria, a person or the agent?

Either can draft them; a person has to own them. An agent drafting its own acceptance criteria and then meeting them is a closed loop with no independent check, which is why finished work here goes to review rather than to done. In practice the agent proposing criteria and a person correcting two of them is faster than a person writing four from scratch.