The backlog audit to run before you point agents at it

Stefan-Iulian Tesoi · 14 September 2026 · 7 min read

A backlog audit is twenty items and four questions. For each item, try to answer from its own text alone: which repository it touches, what observable outcome it wants, what would prove that outcome, and what has to exist first. Anything you cannot answer without asking a colleague is the defect, and it is far cheaper to find now than halfway through a build.

The reason to do it before connecting a coding agent rather than after is that the failure mode changes. A person given an ambiguous item asks a question. An agent given the same item produces something plausible, and you find out at review — having paid for the build, the review and the argument about whether it counts.

What is a backlog audit?

A sample, scored against fixed questions, repeated so the score means something.

It is not a grooming session. Grooming fixes items; the audit only tells you what proportion are broken and in which way, which is the number you need before deciding whether to fix them one by one or change how they are written in the first place. Separating the two matters because a session that does both always becomes grooming — the first broken item is more interesting than the tally, and the tally is the thing that would have told you the tenth item was broken the same way.

This is also not a backlog grooming checklist in the usual sense. A checklist asks whether fields are filled in. An audit asks whether the item can be acted on by someone who was not in the room, which is a question about meaning rather than completeness.

Which four questions does every item have to answer?

These four, in this order, answerable from the item's text without opening Slack.

The fourth is the one teams skip and the one that produces the most expensive failures, because a missing dependency does not look like a defect in the item. It looks like a scheduling accident.

Score each item out of four. Do not weight them — a weighted score invites an argument about the weights, and the raw count is the only number you will still trust in a month.

How many items should you audit?

Twenty, and stop. Not the whole backlog, and not five.

Twenty is enough to distinguish "most of our items are fine" from "most of them are not", which is the only distinction the first audit has to make. Defect-finding by sampling hits diminishing returns fast — Nielsen's argument for small test samples makes the same point about usability studies, where the fifth participant is already mostly confirming what the first four showed. The same shape holds here, and the cost of being wrong is low because the audit repeats.

Take the next twenty items in priority order, not a random twenty. The backlog's tail is full of things nobody will build, and their quality is irrelevant — a defect only costs something when an agent reaches it. Sampling the tail produces a more frightening number and a less useful one.

Budget forty-five minutes to ninety. If it takes longer than two hours you are grooming, which is a useful thing to be doing and a different thing from measuring.

What do you do with the items that fail?

Sort them by which question they failed, and fix the pattern rather than the item.

Most audits produce a lopsided result: thirty per cent fail on acceptance criteria and eighty per cent fail on dependencies, or the reverse. That shape is the finding. Repairing twenty items one at a time treats the symptom and leaves the process that produced them intact, so the next twenty arrive the same way.

• All four missing. The item is a reminder to yourself, not a work order. Send it back to whoever raised it with the four questions attached rather than guessing at answers.
• Repository missing only. Usually a template problem. Add the field, and make it required rather than encouraged.
• Criteria missing only. The commonest result, and the most expensive, because about half of what teams file as rework is a specification defect wearing a code defect's clothes.
• Dependencies missing only. Not an item problem at all — it means sequencing happens in someone's head and has never been written down anywhere.

The audit's output is not twenty repaired items. It is one sentence about how your team writes work, and that sentence is what decides whether the next hundred items are better.

Fix the top failure mode and re-run the audit on the next twenty. That is a backlog health check you can actually repeat, and repeating it is what turns a number into a trend.

How do you score it so the next audit is comparable?

Record three things and nothing else: the date, the count of items scoring four out of four, and the most common failing question.

Three numbers fit in a commit message and survive a year. A spreadsheet with twenty rows and a per-question breakdown does not survive the second month, because nobody opens it. The point of the score is comparison, and comparison needs the same three fields collected the same way, not a richer record collected once.

A first audit on a backlog written for people usually scores between four and eight out of twenty. That is not a crisis and it is not a criticism of whoever wrote them — items written for colleagues are supposed to leave things out, because a colleague can ask. The number only becomes a problem when something that cannot ask starts consuming them.

What Laimonade does with this is the part worth being precise about: it drafts items with the four answers already in them, refuses to mark an item ready when a criterion cannot be tested, and names the missing fact instead of inventing a plausible one. It does not mark work done — a person always takes that step. If you want to see the shape of an item that passes all four questions, a backlog an agent can actually read sets out the four defects this audit is looking for, and getting started is where to point it at one project. How Laimonade works covers what happens to an item after it passes.

Run the audit again a month later, on the next twenty. If the score has not moved, the grooming changed and the writing did not.

Frequently asked questions

How long does a backlog audit take?

Forty-five to ninety minutes for twenty items, once you stop fixing them as you go. The fixing is what turns an hour into an afternoon, and it is also what stops you finishing the sample — the tally is the deliverable, and a partial tally answers nothing. Score all twenty first, then decide what to repair.

Should you audit the whole backlog or just the next sprint?

The next twenty items in priority order, which usually spans more than one sprint and never the whole backlog. Items nobody will build cannot cost you anything, and including them makes the score worse without making it more useful. The backlog's tail is a storage problem, not a quality one.

Can the audit be automated?

The scoring largely can: whether an item names a repository, carries testable criteria and declares dependencies is checkable by a machine, and that is most of the four questions. What resists automation is judging whether the stated outcome is the one the requester actually wanted, which needs somebody who knows why the work was asked for.

Is this the same as a definition of ready?

They overlap and they are used differently. A definition of ready is a gate applied to one item at the moment it moves; an audit is a measurement taken across a sample, on purpose, to produce a number. A team can have a definition of ready that everyone agrees with and still score six out of twenty, which is exactly the situation worth discovering.