Agile in the Era of Coding Agents

Look at a sprint board near the end of a sprint and you’ll see something that didn’t used to happen. A lot of the tickets look finished. The code is written. Pull requests are open. In some cases the work was written days ago. But not much of it has merged, and even less of it is in front of users. The sprint ends, the board rolls over, and the same tickets show up again in the next one — not because nobody worked on them, but because the work is waiting.

Waiting on what depends on the ticket. A review nobody has had time for. A question about what the ticket actually meant. A decision that has to come from a person, and that person has twelve other decisions queued in front of it. The coding part is rarely the thing holding it up anymore.

That makes sense when you think about what a sprint was for. Two weeks was a reasonable batch size when writing the code took most of the two weeks. You’d plan a set of tickets, people would go off and build them, and near the end you’d find out how it went. Planning was mostly a question of how much a team could write in the time available, and for a long time that was a fair way to run it.

Agents change the timing, not the need for the meeting. If a ticket is clear, an agent can have a first version ready quickly, sometimes the same day. After that the ticket enters the same human process it always did — review, questions, changes, approval — and that process runs at the speed it always ran. So a ticket can be “written” on Tuesday and still be nowhere near shipped the following Friday. The sprint boundary arrives in the middle of that, and we act surprised that the board doesn’t line up with the calendar.

Planning makes it worse, in a quiet way. In planning we still size work roughly by how long it will take to build, and then we fill the sprint up to that estimate. Building is now the short part. If we fill a sprint based on writing time, we start more work than the team can review, decide on, and finish. The charts can look good while this happens, because most of them count what got started or what got written. I covered a study a few weeks ago — 718 companies, output up about 30% after adopting coding agents, resolved issues basically unchanged — and that gap is what a sprint board full of waiting tickets looks like from the inside.

I’ve started treating the end of the sprint differently, and it’s a small change. We still meet every two weeks. We still talk about what we planned to do. But the part I pay attention to is a simpler count: what merged, what shipped, and what is still waiting, and why. Carryover used to read as a failure to me — the team took on too much, or somebody had a bad two weeks. Now most carryover is waiting, and naming it that way changes the conversation. If eight tickets are stuck in review, that’s useful information about where the team’s time actually needs to go. If they’re stuck on decisions, that’s information for me.

I don’t have a replacement process to sell here. Shorter sprints wouldn’t fix it; the queue would just be measured more often. Planning further ahead doesn’t help either, because an agent will happily start next month’s work this week and add it to the pile. The limit now is how much work the team can get through review and out the door, and until planning respects that limit, the sprint will keep filling up with work that is written and not done.

I still like the two-week rhythm. People need a regular point to stop, look at what’s in front of them, and argue about what matters next. I just don’t trust the sprint to tell me how much software we finished anymore. It tells me what we started, and it tells me where things are waiting. At the moment, the second one is the more honest report.