Running a sprint when your team is part agents

Standup, Wednesday. Someone is giving their update, and it is a good one, but halfway through you notice that most of what actually changed in the repo last night is not in it. Three agent sessions ran after everyone logged off. One of them reworked the retry logic in the payments module. Nobody standing in the circle is going to mention that, because nobody standing in the circle did it, and the sessions are not here to speak for themselves.

So you get a clean report on the third of the work the humans did by hand, and a shrug for the rest. The ritual has not broken, exactly. It is doing what it always did. It is just describing a team that shows up to standup, and yours no longer entirely does.

The ceremonies assume things that stopped being true

Agile did not fail here. It was written for a particular kind of team, one where capacity is roughly knowable, where the people doing the work are the people in the room, and where a shared view of who is doing what is maintained by those people talking. Every ceremony leans on at least one of those, and a coding agent quietly breaks all three.

You plan against the team's capacity, but nobody can say what an agent's capacity is. You hold a standup where each person reports what they did yesterday, and nothing reports what four sessions did overnight, because sessions do not attend standup. You set a work-in-progress limit and nothing enforces it against something that can open five threads while you make coffee. None of these are exotic failures. They are the ordinary ceremonies doing exactly what they always did, against a team that is no longer shaped the way they assume.

This only gets worse with more people, because each developer's agents are invisible to everyone else's. If you are not sure you are even running several agents at once, that is the more basic point, and we made it in you are already running a multi-agent system. This post assumes you are, and asks what it does to the way you plan.

The obvious question is whether the tools already handle this. One of them handles part of it. Claude Code's Agent Teams lets a lead spawn a group of its own sessions that share a task list and claim from it, which is real coordination inside that group. But the group is one person's, one vendor only, and it ends when the session does. It is not the sprint. The sprint belongs to the whole team, it runs across people and the different agents each of them brings, and it has to outlive any single session. That is the layer the ceremonies are about, and no one tool's built-in team reaches it.

The cockpit already solved a version of this

There is a version of this problem that gets solved in a cockpit. Current fighter programmes pair one crewed aircraft with several uncrewed ones, and the pilot's job shifts from flying to allocating: which aircraft goes where, which one takes what, and above all making sure two of them do not go after the same thing while something else goes untouched. The demanding part was never whether each aircraft could fly. It was deconfliction.

What makes that survivable is worth borrowing. The pilot does not hold every aircraft's position in their head and talk to each one in turn. A datalink keeps one shared picture, every aircraft reads from the same picture, and the pilot commands intent against it. Take the shared picture away and the job degrades into manual deconfliction, which is more than one person can do at speed. The shared picture is infrastructure. It is not something the pilot maintains by hand.

A sprint is the same shape in slower motion. The work is genuinely parallel, the actors cannot see each other, and somebody has to make sure two of them do not chase the same ticket while another sits untouched. Try to be the datalink yourself, holding every session's state in your head and dispatching by memory, and you become the bottleneck you were trying to remove.

Break it down, or become the message bus

So a choice arrives, usually without anyone noticing it is a choice. Either you break the work down far enough that each ticket carries its own scope and context, so an agent can be handed one and left with it, or you keep the context in your head and spend the day dispatching: this session takes the migration, that one waits, this one needs the background it lost when it restarted.

The second is not a workflow. It is a person being used as a message bus, and it does not survive a second developer doing the same thing at the same time, because now two message buses are routing the same agents against the same repository with no idea the other exists. The first option is the one that scales, and it is less new work than it sounds, because it is the definition-of-ready discipline a sprint is supposed to have anyway. A ticket an agent can pick up is a ticket with a scope and an acceptance criterion, which is the same ticket a new hire could pick up.

What a board built for agents does

The difference between that discipline holding and slipping is whether the board enforces it or merely hopes for it. A board built for agents can refuse to hand out work that has no scope, so definition-of-ready stops depending on whether anyone felt like it on planning day. Human trackers can require fields at creation too, and good teams set them. What they do not have is a hand-out step: the moment an agent asks for its next piece of work, where the board can decline to give it anything that is not ready. An agent can already query Jira or Linear for whatever sits in a ready column and take the top hit, but that filter is one the agent wrote, not one the board enforces, and nothing on those trackers stops an agent reaching for a ticket that was never made ready. That gate exists only once the board is the thing agents pull from, which a tracker built for people assigning work to people never had to be.

The sprint boundary works the same way. On our own board the running sprint is human-owned: an agent can create work, fill in what it needs, and schedule it into a sprint you have not started yet, and it cannot add to the one in flight. The most it can do to the current sprint is tell you it thinks something belongs there. Leases cap how much a single agent holds at once, a work-in-progress limit that enforces itself rather than one written on a wall. And because every attempt is recorded against the ticket, the standup question of what happened yesterday has an answer without anyone having filed a note.

The one thing it does not give you back is velocity. You cannot forecast an agent's throughput the way you learned to forecast a person's, and you stop trying to. What you plan against instead is what is ready to hand out and how much runs at once, which are the two levers you can actually set.

None of that runs your agents for you. An orchestrator does that, spawning and supervising sessions on your machine, and it sits alongside this rather than instead of it. What the board does is decide, across every session and every person, which one is allowed to hold which piece of work. That is the part the ceremonies used to do by conversation, and it is the part that stopped scaling.

That board is My Fordyce: a backlog with its own MCP server rather than a wrapper over somebody else's tracker, which is what lets it enforce readiness and arbitrate claims at all. It is 37 tools, 12 of them coordination, one URL and a key, $30 a month. You can see how the hand-out works end to end, or compare it against the trackers and orchestrators you already run. The Model Context Protocol is the open standard underneath it, so whichever agent your team prefers reaches the same board.

Common questions

How do you run a sprint when part of the team is AI agents? Plan the sprint the way you already do, and change two things. First, tickets an agent will pick up need a scope and an acceptance criterion written before the sprint starts, because an agent cannot infer them from the room the way a developer can. That is the definition-of-ready discipline sprints are supposed to have anyway. Second, decide explicitly what agents may take. On our board the running sprint is human-owned: an agent can create work and schedule it into a sprint you have not started yet, and it cannot add to the one in flight. Leases cap how much any single agent holds at once, which is a work-in-progress limit that enforces itself, and because every attempt is recorded against the ticket, the standup question of what happened yesterday has an answer nobody had to file.

How do you stop AI agents taking work outside the sprint? Make the sprint boundary something the board enforces rather than something people remember. On My Fordyce the active sprint is human-owned: an agent can create a ticket and schedule it into a sprint you have not started yet, but it cannot add itself to the one that is running. The most it can do to the current sprint is tell you it thinks something belongs there. Combined with a per-agent cap on how many tickets one identity can hold at once, that keeps a busy agent from quietly widening the scope you committed to.

Where that leaves the ceremonies

None of this is an argument against agile. The ceremonies are fine. They just cannot carry a job they were never handed, which is accounting for work done by things that do not sit in the room. Give them a shared picture underneath, one that does not depend on everyone remembering what their agents did overnight, and standup goes back to being standup. See how the hand-out works, or open the demo and start from the board the agents read.