Who owns the backlog when agents write the code?
Stefan-Iulian Tesoi · · 6 min read
Backlog ownership splits in two. A person owns what the backlog is for — priority, scope, and whether a thing should exist at all. Something else owns whether each item is in a state an agent can execute, which turns out to be a continuous job rather than a weekly meeting.
Both halves used to belong to one person because there was no reason to separate them. That reason arrived with the agents.
What does backlog ownership mean now?
Ask who owns the backlog and you usually get a name. Ask what that ownership consists of and you get two answers that have been living in one job title — and once coding agents are consuming the backlog, the two need different people.
The first is a set of judgements: this before that, this is worth building, this is not. Those are claims about a business and they need someone accountable for being wrong about them.
The second is a state: every item near the top is complete enough that work can start without a follow-up question. That is not a judgement. It is maintenance, and it decays — not because anyone forgets how, but because it is the first thing dropped on a week when four items are waiting and the agents are idle.
Where do the two halves split?
Cleanly, and the line is easier to see written down than it is in a meeting:
| Deciding | Keeping executable | |
|---|---|---|
| Output | Priority and scope | Items that can be dispatched |
| Cadence | Weekly, in a conversation | Continuous, per item |
| Fails by | Building the wrong thing | Building the right thing wrongly |
| Needs | Business context | The item's own text |
| Belongs to | A person | An AI product owner |
The last row is the claim, and the row above it is the reason. Deciding needs context that lives outside the backlog — what a customer said, what the roadmap promised, what the company can afford this quarter. Keeping an item executable needs only the item: is the repository named, can each criterion be checked, is the dependency sequenced before this. That is the half a machine can hold to a standard on a Thursday.
Why did grooming stop being a weekly meeting?
Because the batch stopped making sense. Grooming was scheduled weekly for a good reason: items were consumed at roughly the rate a person could build them, so a week's worth of readiness lasted a week.
At forty minutes an item, a week's worth of grooming is gone by Tuesday. Nothing about the meeting is wrong; the interval is wrong, and there is no interval that fixes it. The work has to happen per item, immediately before dispatch, or the queue in front of specification grows all week.
That changes what the human meeting is for rather than removing it. What remains is the part no system can answer: of the things in flight, which has become the wrong thing to be doing.
How do you keep one backlog rather than two?
The failure mode worth guarding against is a split into a "real" backlog somebody trusts and a "tidy" one the agents read. Once those exist, every item has to be written twice and one of the two is always stale.
Three things have held it together for us:
- One store, two roles. Priority and readiness are fields on the same item, not separate systems. An item can be top priority and not ready, and that combination must be visible rather than reconciled.
- Readiness never overrides priority. The AI product owner does not reorder work because one item is easier to specify. It reports what is ready; the person decides what matters.
- Refusals surface as questions, not as guesses. An item that cannot be made executable comes back with the missing fact named. Guessing is how two backlogs start.
A worked example: one item, two owners
"Customers keep asking for CSV export" arrives from support. The person decides: yes, this sprint, second priority, and only for the transactions table — not everywhere, not yet.
Everything after that is the other half. Which repository holds the transactions table. What the file should contain, in columns. What happens to a two-million-row export. Which criterion proves it worked, and what proves the timeout path works too. Whether the item depends on the pagination work sequenced later, and if so, which of the two moves.
None of those questions needs the customer conversation. All of them need answering before a coding agent starts. And the person who had the customer conversation is the worst use of an hour on the list, which is the practical case for splitting the role rather than the theoretical one.
Our own backlog runs this way, which is how the four failure modes got found in the first place. What an AI product owner actually does covers the half that is handed over; how Laimonade works covers the mechanics of the split, and the sprint workflow covers where each half lands in a week.
For the older version of this argument, the Scrum Guide is worth rereading. Its list of product owner responsibilities has always included the backlog being "transparent, visible and understood", and has always been silent on who does the typing. That silence is what one person absorbed for twenty years, and it is why backlog grooming roles were never written down separately: there was only ever one.
Frequently asked questions
Does every team need a dedicated product owner?
No, and most small teams should not hire one for this. What they need is for the two halves to be visible separately, so the deciding gets an hour of the right person's attention and the specifying does not quietly eat their Thursday. On a team of five that usually means the founder or tech lead keeps the judgement and hands over the maintenance.
What happens to grooming meetings?
The refinement half goes away, because per-item work cannot be batched into a slot. What is worth keeping is shorter and different: a conversation about whether the things in flight are still the right things. Teams that keep the old meeting and add continuous grooming end up doing the work twice and resenting the meeting.
Who breaks the tie between priority and readiness?
A person, always. The tie looks like this: the most important item is not ready and the second is. Reordering on readiness is how a backlog silently becomes a list of whatever was easiest to specify. The right move is to say the top item is blocked on a named missing fact, and let whoever owns priority decide whether to answer it now or take the second item.
Can two people own the two halves instead?
Yes, and it works well when both exist. Splitting specifying from reviewing across two people is a real option and often the first thing to try. What does not work is assuming the specifying fits in the gaps of somebody's existing job, because it is the part that silently gives way when the week gets full.