Agent Scrum: Running a team of AI coding agents in two-hour sprints

A sprint methodology for continuous software development by AI agent teams, with observations from 324 sprints

Dave Remy · Working paper · Version 0.1 · 28 October 2026 · CC BY 4.0

Over 38 days, a fleet of AI coding agents ran 324 two-hour sprints around the clock on a real product backlog. In the 90 sprints run by a dedicated scrum-team agent, 79% of committed stories reached done inside the sprint and ceremony took under five minutes per sprint. The slowest stage was not writing code: the median time from approval to merge equalled the median time to build. Compounding was the weakest part: 119 of 159 retrospective actions are still open. We call the method that produced these numbers Agent Scrum. It keeps Scrum's core devices (a time-boxed sprint, a committed sprint backlog, story points, velocity, a Definition of Done and a retrospective) and changes their scale and constraints. Sprints last two hours instead of two weeks, capacity comes from model rate limits instead of headcount, and cost is measured as token velocity, the tokens consumed per merged story point. Conversation and planning stay with one human-facing product-owner agent, while execution moves to scrum-team agents created on demand. The human stakeholder spends under two hours a day, and no sprint waits for them. Horizontal scaling to several teams is designed but untested because of token budget.

KeywordsScrum, agile methods, AI coding agents, multi-agent systems, compound engineering, software factory

AI coding agents can now take an issue, write the change, test it and open a pull request with little human help. Once a developer has more than one such agent, the question changes from how to prompt an agent to how to organize a group of them. Work has to be chosen, sized, assigned, reviewed, merged and learned from, and the human who owns the result has limited attention.

Software teams have faced this coordination problem before, with people. Scrum is the most widely used answer. This paper describes how a single developer's agent fleet arrived at a version of Scrum by trial and error, which parts carried over unchanged, which needed new meanings, and which did not apply. We call the result Agent Scrum and propose it as a methodology others can test.

The author spent years on, and running, human Scrum teams, and came away finding much of it overbearing: a great deal of ceremony, much of which seemed unnecessary for agents. Scrum was therefore not the plan. The first sprints had two motives: to put a boundary around work that otherwise ran without end, and, as much as anything, context management. An agent's context window fills as it works, and quality falls as it fills; a sprint gives the agent a clear, regular point at which to write down its state, clear its context and start fresh. Each later change (points, velocity, a fixed deadline, retrospectives, a separate team) was adopted reluctantly, one at a time, to answer a specific failure. That history matters to the argument: the Scrum devices reappeared because the same problems reappeared, not because we copied a process.

The results were better than that reluctance predicted. Measured against goals most practitioners of applied AI engineering share, the method delivers several of them at once. A software factory that runs around the clock falls out of the sprint loop. Compound engineering falls out of the retrospective. Scrum also brings a large body of existing knowledge (estimation, the time box, the definition of done, the retrospective) that agents and their human can draw on instead of inventing, and its built-in risk management and early feedback carry over intact: small committed batches, a hard boundary, and finished work every two hours. So far, Scrum and agents appear to fit well, and some of the problems that weigh on human Scrum teams have not arisen. It is still early.

The contributions are (1) a description of the method and the mapping from Scrum's roles, artifacts and ceremonies to agent equivalents; (2) a mechanism for enforcing a hard sprint deadline on agents that cannot be interrupted mid-task; (3) measurements from a reference implementation; and (4) an account of open problems.

This section is for readers who have not worked in Scrum. Readers who have may skip to Section 3. Section 6 lists the terms this paper uses, and Section 11 places Agent Scrum among related work.

Scrum organizes software work into short, fixed periods called sprints, traditionally one to four weeks. Before a sprint starts, the team holds sprint planning: it takes the highest-priority items from the product backlog (the ordered list of everything the product might need) and commits to a subset, the sprint backlog. The items are usually written as user stories, and a team may split a story into smaller tasks.

Each story is estimated in story points, a relative measure of effort and risk. A 3-point story is roughly three times the work of a 1-point story. Points have no unit and mean nothing outside the team that assigns them. Their value comes from consistency: over several sprints, the number of points a team completes per sprint, its velocity, becomes a usable forecast of what it can commit to next time. The ratio of what a team committed to what it finished is often called its say/do ratio.

The sprint is time-boxed: its end date does not move. Work that is not finished does not extend the sprint; it returns to the backlog. The fixed end forces regular decisions about scope and makes velocity comparable from sprint to sprint. A story counts as finished only when it meets the team's Definition of Done, a shared quality bar such as "reviewed, tested and merged".

Scrum has three roles. The product owner orders the backlog and decides what is worth building. The developers do the work. The scrum master runs the process and removes obstacles. It also has a small set of ceremonies: planning, a short daily stand-up for coordination, a sprint review that demonstrates the finished work to stakeholders, and a retrospective in which the team examines how it worked and chooses improvements. Teams often display the sprint on a board with columns such as To do, In progress and Done, a practice borrowed from Kanban.

Two newer terms are relevant. Compound engineering describes a practice in which every unit of work leaves the system better at doing the next unit, for example by turning each mistake into a rule, test or tool that prevents it from recurring. A software factory describes a production line for software in which much of the building is automated and humans supervise the line. Agent Scrum treats the retrospective as the place where compounding happens and the sprint loop as the factory line.

The reference implementation runs on one Linux workstation. A terminal multiplexer (tmux) holds a fleet of persistent AI agents, each a long-running Claude Code session with a defined role: chief of staff, health, finance, communications, research, marketing, customer support, operations, and a chief technology officer (CTO) agent that owns engineering. Each agent has its own message channel to the human owner and can message the others. Scheduled work runs on system timers, not inside the agents.

Engineering work spans several repositories: the fleet's own infrastructure, a consumer mobile and web product, a Rust desktop application, and a machine-monitoring tool. Work is tracked as GitHub and GitLab issues. The developer of record is one person, who acts as stakeholder and final decision-maker but writes little of the code.

Human stakeholder priorities, taste, decisions

CTO agent conversation, backlog, planning, exceptions

Other role agents health, finance, ops, research…

Scrum team agent created on demand runs one sprint at a time, merges, wraps, retro, sprint review

committed backlog

Further teams (designed; budget-limited)

Developer one per story

Developer own worktree

Reviewers one or two, by risk

Figure 1. Roles in the reference implementation. The CTO agent talks with the human and plans; the scrum team executes. Dashed: further teams, which the design supports but the token budget does not yet fund.

4How the method evolved

4.1 Sprints inside the CTO agent (sprints 1 to 234)

The first sprint ran on 20 September 2026. The CTO agent chose a few issues, estimated them in points, started developer agents for each, reviewed and merged their pull requests, and at the end wrote a sprint report with a name, a plan, estimates against actuals, costs, lessons and a retrospective. The report was published as a web page for the human owner to read. In practice it served as the sprint review.

Sprint length settled quickly at two hours, on fixed time boxes that start on odd hours (01:00 to 03:00, 03:00 to 05:00, and so on). As in human Scrum, the length is a choice, not a law (see Sections 7 and 9). By the end of September the loop ran unattended: at the end of each sprint the CTO agent wrote a handoff note, cleared its own context and resumed into the next sprint.

This worked, and it exposed a structural problem. The CTO agent was doing two jobs with one context window. Running a sprint fills the context with build logs, review verdicts and merge state. Talking with the owner about direction, priorities and design needs the same context for a different purpose. Each job degraded the other: sprint state crowded out the conversation, and a conversation in the middle of a sprint delayed merges and wraps.

The first design gave the sprint its own permanent agent, provisionally named after Jeff Sutherland, one of Scrum's creators. While designing it, we noticed that nothing limited the design to one such agent. If a scrum master is an agent, a second team is a second instance of the same definition with different repositories assigned to it.

The design that shipped on 19 October therefore defines a scrum team as a class of agent, started on demand by the launcher as a numbered instance. The CTO agent keeps the conversation with the owner, the product backlog, sprint planning and exceptions. The scrum team runs exactly what it is handed. A pilot began on 19 October with sprint 235, and since 20 October the dedicated team has run every sprint while the CTO agent runs none. 90 sprints have run that way at the time of writing.

Table 1 maps Scrum's elements to their Agent Scrum equivalents. Most map one to one. The changes are in who plays the roles and in the time scale.

Table 1. Scrum elements and their Agent Scrum equivalents.

Planning works at four horizons, from months to hours.

A story may enter a sprint backlog only when it meets the Definition of Ready: the product owner has made four reads of the story, each within 12 hours of its sprint (the issue's log, its open pull requests, its last three comments, and a search of the main branch for an existing fix), sized it, and written a brief and a stop rule. Stories of 5 or 8 points are split or planned first; every sprint also runs one planning-only story that prepares a later one. Each sprint backlog carries ready Overflow worth at least one and a half times its committed points, plus two or three one-point planning stories, so that a sprint whose commitment finishes early still has useful work. These rules came from measured idle time: on 20 October the team finished its commitment about 40 minutes early in most sprints because nothing ready was left, and on 25 October one sprint sat idle for 45 minutes with no Overflow. The Overflow ratio was raised from one to one and a half on 28 October, after the team ran dry three times in one night.

A sprint proceeds as follows. When the sprint starts, the scrum team checks that its sprint backlog is committed and assigned to this team and this sprint, takes a lease on the repositories in scope (so no other team can merge there), names the sprint, records the commitment and starts the first wave of developers. Each developer works in an isolated work