Agile with AI Agents: Scrum Reimagined

Agile is two things wearing one name: a set of values and a set of practices built to serve them under human constraints. When the implementers become coding agents, the values hold up remarkably well and the practices need rework. Keeping the distinction straight is the whole game, because most “agile is dead with AI” takes are really about the practices, and most “nothing changes” takes are really about the values.

The four commitments at the heart of the manifesto map cleanly, and several get easier with agents. Working software over comprehensive documentation was never a license to skip specs, and it is not now, but agents ship running code from a tight spec faster than any team could, so the increment-of-working-software cadence tightens rather than loosens. Small increments are natural when the unit of work is a single story an agent finishes in one session. Fast feedback arrives in minutes instead of days because the loop from spec to reviewable PR is short. And inspect-and-adapt, the deepest value, still applies, you just inspect specs and PRs instead of burndown charts.

What breaks is the machinery that existed to manage humans. Velocity and story points were a forecasting tool for how much human effort fit in a fixed window; with agents that vary in speed and cost, pointing implementation adds little. Timeboxed sprints imposed a rhythm so a team could plan, focus, and demo together; a two-week box makes little sense when a story ships the afternoon it is specified. And the daily standup as a status ritual, what did you do, what will you do, what is blocking you, surfaces information that a live board already shows. The values are the constant; the ceremonies are the variable.

None of the scrum ceremonies disappear outright. Each exists to make a decision or surface information, and those needs persist, they just take a different shape when the doer is an agent and the human is a director. The useful move is to translate each ceremony to its agent-augmented equivalent rather than either cargo-culting it or throwing it away:

Two shifts are worth naming. The standup collapses because its whole purpose, making distributed human state visible once a day, is served continuously by a kanban board where each story is a card. And the retro sharpens: instead of soft reflection on team dynamics, you get a concrete artifact to inspect, the spec that under-specified scope, the acceptance criterion that was untestable, the harness step that let a bad diff through. The management loop underneath all of this is covered in project management for AI coding agents.

Agile always had a unit of work, the user story, and its ideal has not changed: independent, small, testable. What changes is the definition of “small enough.” The right size for an agent story is one an agent can implement in a single worktree, in one session, against a clear definition of done. That is a sharper constraint than “fits in a sprint,” and it does more work.

A story sized this way has three properties. It is specifiable: you can write down scope, the files in play, acceptance criteria, and explicit exclusions without hand-waving, the discipline of spec-driven AI development. It is isolatable: it owns its files, so it can run on its own branch without colliding with other in-flight work. And it is reviewable: it produces one PR small enough to read against its spec in minutes, not a sprawling diff you rubber-stamp. If a story fails any of the three, it is really several stories, and splitting it earlier is cheaper than rejecting a tangled diff later.

Agile always cast the developer as the one doing the work and the product owner as the one deciding what work mattered. With agents, one person often holds both hats, and the balance tips hard toward deciding. The human's day is no longer spent typing implementations; it is spent at the edges of the loop, defining work going in and judging work coming out.

This is the same redistribution agile always wanted, developers freed from grunt work to focus on value, taken to its logical end. The grunt work is now the agent's, and the human leverage lives in the two gates: approving the plan before code exists, and judging the diff before it ships. How you hand a spec to the right agent is its own craft, see how to assign tasks to AI agents.

The danger of a continuous flow with cheap parallelism is that “agile” quietly becomes “launch everything at once.” Agile's answer predates agents: limit work in progress. The lean/kanban WIP limit was always the discipline that kept a pull system from turning into a pile, and it matters more, not less, when starting another unit of work costs one click.

Two mechanisms keep it sane. The first is a real WIP limit tied to your review budget, not to how many agents you can technically start. Every running agent produces a PR that deserves a real read; if you can carefully review three or four in a working session, that is your limit, and unreviewed PRs are inventory, not progress. The second is isolation: each story on its own git worktree and branch, so parallel work never contaminates a shared tree and a bad run is disposable rather than contagious. The mechanics of running several agents this way without collisions are in the multi-agent coding workflow guide.

Concretely, a working session as the human director looks less like a scrum team's day and more like a tight, repeating loop. There is no morning standup and no sprint boundary; there is a backlog, a board, and a review queue you keep flowing:

1. 1

   Triage the backlog

   Open the board and decide what matters next. Reorder cards by priority, split anything too big to hand to one agent, and pull the top few into refinement. This is the product-owner beat that used to be sprint planning, done in minutes, not a two-hour meeting.
2. 2

   Approve three specs

   For each pulled story, review the drafted spec, scope, files, acceptance criteria, exclusions, and either approve it or tighten it. This is your cheapest control point: a minute spent sharpening scope here saves a rejected PR later. No agent starts until the spec is approved.
3. 3

   Agents run in parallel

   On approval, each story gets its own worktree and branch, and an agent implements it while you move on. Three stories run at once, isolated from each other. Your attention is free for the next batch, not tied to a terminal.
4. 4

   Review three PRs

   As stories complete, each opens one PR with its spec as the description. Read the diff against the acceptance criteria: accept, request changes, or discard and re-spec. With agents, throwing work away is cheap, so a clean re-run often beats a long correction thread.
5. 5

   Merge, then repeat

   Merge the accepted PRs, closing the loop, story, spec, diff, and PR become the durable record of why the change exists. Then pull the next stories off the backlog. The sprint never starts or ends; the flow just continues.

The failure modes are consistent, and each is a way of getting the values/mechanics split wrong, either dragging dead human machinery onto agents, or dropping a value the machinery used to protect. Four recur:

You can run all of this by hand, a backlog file, tmux panes, and git worktrees will do it, and it is worth doing once to feel where the overhead bites. AIDEN's contribution is making the reframed ceremonies structural rather than a matter of discipline. It is a cockpit over your existing Claude Code and Codex CLIs, so BYO inference: your subscription or API key, your models, one board.

The board is organized the way agile-with-agents actually flows. Projects hold Epics, Epics hold Stories, so backlog refinement and planning happen as structure, not meetings. Each story goes through a spec approval gate, no agent codes without an approved spec, which is refinement and the plan-review gate made mandatory. On approval, the story gets its own git worktree (isolation and WIP safety) and produces one PR per story reviewed against its spec (the sprint review, per story). Crucially, the board tracks work, not sessions: a single continuous flow of stories and their PRs, which is the continuous sprint made concrete. PR handling itself can be streamlined further, see the AI PR automation workflow. Solo is $19/month, and it is free for one project, enough to run your first continuous flow end to end.