Process

Agents don't need sprints. You do.

We pulled ten days of our own ticket history to see where an agent's time actually goes. It mostly doesn't go anywhere. The ticket sits.

A pilot, not a study: one project, one human reviewer, ten days, 98 tickets that an agent finished and whose pull request merged. We measured the stretch between a ticket's creation and its merge, then asked how much of that stretch had an agent actually working on it.

Share of a ticket's open time spent waiting on someone, not an agent.

The median ticket spent 92% of its life with no agent touching it. Take the mean instead and it's still 76%. Even the best quarter of tickets, the ones that moved fastest, lost 58% of their time to queues.

Two caveats worth stating plainly. Agents write their phase records in bursts, often after the work is done, so the gap between a claim and the last recorded phase is the best read we have on agent time, and it probably runs low. Sessions themselves stay open past that point too, a median of 2.8 hours, because nothing closes one when the work ends. And the wait before a claim isn't only a queue for a person: we run at most three agents at once on this project, so part of it is a queue for an open slot.

None of that changes the shape of it. Once an agent writes the code, the time goes to being shaped, picked up, reviewed, approved and merged. The bottleneck sits with people, at every one of those handoffs.

Where the hours go

Stretch of a ticket's lifeMedianp75p90
Created until an agent claims it2.3 h7.9 h14.7 h
Claimed until the agent's last phase record0.4 h1.7 h11.6 h
Agent's review record until the PR merged1.0 h10.6 h15.3 h
Created until the PR merged14.4 h18.9 h26.6 h

So should agents have sprints?

No. A sprint does two jobs: it forces a batch of work to a close, and it creates a fixed moment to inspect and adapt. An agent needs neither on a timebox.

The unit of agent work is already small. One ticket, one session, a median under half an hour of recorded work on our own project. A sprint that short is just a ticket with extra ceremony. An agent doesn't tire and can re-plan the moment a queue changes, so the fatigue Scrum's estimation assumes doesn't apply; the real cost is tokens and which model the ticket needs. And a sprint commitment is exactly what makes a stakeholder's change of mind expensive. Without one, reordering the queue costs nothing.

People still need rhythm. An interruption costs a person a context switch that an agent doesn't pay. So we run continuous flow for agents and cadences for people: a review window a few times a day, a replenish prompt when the ready queue runs low, a release whenever there's approved work to ship, a weekly retro. A team that still wants to report in sprints can turn on a sprint lens on top, which orders and reports on work without putting agents on a clock.

We kept a goal per release, small increments, an inspection loop and a retrospective from Scrum. From Kanban: pull, visible queues, work in progress limits. From Shape Up: a person sets what the work is worth, not an estimate of how long it takes.

What we built instead: Attention Flow

We built this into Aidelix itself. Attention Flow replaces the generic to-do columns with seven that name who moves next: Shaping, a person refines the idea; Ready, an agent pulls it; Building, the agent works it; Needs a human or Review, a person's turn; Ready to ship, waiting on a release; Shipped. Every column says whose move it is, so nothing sits where nobody owes the next step.

Review and Needs a human share one limit, because both queue for the same scarce thing: a person's attention. When an agent would push past that limit, it gets a warning, not a refusal, and a nudge to finish open work first rather than start more of it.

Attention Flow pairs with Manifest flow, the branching strategy we shipped alongside it, which lets a finished ticket wait on its own branch until a person puts it in a release, instead of sitting merged and going stale.

Start free