Sprint Planning with AI Agents: A Practical Guide

Sprint planning is a rationing ritual. Its whole shape, points, velocity, capacity in hours, the two-week box, exists because human implementation was the scarce resource. You could only build so much per cycle, so the hard question was which few things to commit to, and the artifacts all answered that question. Estimation was really capacity accounting for a small, expensive, slow team.

Coding agents remove that specific scarcity. You cannot hire five engineers for an afternoon, but you can start five agents in five minutes, and stop them without a conversation. Implementation stops being the binding constraint. What does not change is the point of the exercise: a sprint still exists to produce a shippable increment, a coherent, verified improvement to the product by the end of the cycle. Planning still means choosing what to commit to and sequencing it sensibly. The goal is stable; the constraint under it has moved.

It moves to two places. Upstream, an agent ships only as fast as someone can write features precise enough to hand it, so spec throughput becomes a limit. Downstream, agents produce plausible diffs faster than anyone can read them, so review bandwidth becomes the other limit. A sprint plan that ignores both, and commits to a pile of work because “the agents are fast,” just relocates the bottleneck to review and calls it done. The broader version of this inversion is covered in project management for AI agents.

The old estimation conversation asked, roughly, “how many hours is this, and do we have them?” That question is now mostly irrelevant, agent hours are cheap and parallel. The question that replaces it is about shape, not size:

This reframes estimation around two properties. The first is splittability: whether the feature is already one independent, coherent change or hides several. A feature that is really three features comes back as a diff that is really three diffs, reviewable only as a lump, and you end up accepting or rejecting all three at once. Splitting is the planning work, and it happens before the agent runs, not after.

The second is review cost: how long a competent reviewer will need to read the resulting diff against its criteria and decide. Review cost, not build cost, is what a sprint actually spends, because building is cheap and reviewing is the human act that gates the merge. Estimating in review cost keeps the plan honest, it counts the resource you are actually short of. Writing the criteria that make a feature checkable at all is the practice of spec-driven AI development.

The planning meeting keeps its skeleton, define, decompose, commit, sequence, but the emphasis shifts to specs and review budget. A cycle plans in six steps:

1. 1

   Clarify the outcome

   Name the shippable increment for the cycle in one or two sentences: what will be true of the product at the end that isn't true now. This is the same goal-setting a human sprint does; it anchors everything downstream and keeps the feature list from becoming a wish list of unrelated agent tasks.
2. 2

   Decompose into independent features

   Break the outcome into features that are each one coherent change, and as far as possible independent of one another. Independence is what lets features run as parallel agents later; where two features must touch the same code or depend on each other's output, note it now rather than discovering it as a merge conflict mid-cycle.
3. 3

   Write and approve specs

   For each committed feature, write the spec, scope, files in play, verifiable acceptance criteria, explicit exclusions, and approve it. An unspecified feature is not plannable; it is a decision you have deferred to the agent. The spec is also your review contract, you will judge the diff against it, so writing it is half the review work done up front.
4. 4

   Set WIP by review capacity

   Decide how many features can be in flight at once, and cap it at what your reviewers can actually keep up with, not what the agents can run. This work-in-progress limit is the single most important number in an agent sprint: it is what prevents a queue of unreviewed diffs from silently becoming the real backlog.
5. 5

   Sequence for dependencies

   Order the committed features so independent ones can run in parallel and dependent ones run after what they need, or after a shared interface contract is agreed. Sequencing is now about data and code dependencies between features, not about who has bandwidth, since bandwidth is no longer scarce.
6. 6

   Run the loop

   Start approved features up to the WIP limit, each in its own worktree; review each returning diff against its spec; merge or re-run; pull the next feature when a review slot frees. The cycle is a steady flow through the review gate, not a big-bang commit followed by a scramble.

Run for one feature this is trivial; run for a dozen in parallel it is a coordination problem, which is why teams converge on a board, one column per stage, one card per feature. The board patterns are covered in AI kanban for developers and the multi-agent coding workflow.

The familiar estimation vocabulary does not disappear so much as get re-pointed. Each old habit has an agent-era equivalent that measures the constraint that now binds:

The through-line: stop estimating effort and start estimating reviewability. Effort was the scarce thing when humans coded; reviewability is the scarce thing when agents do. A plan built on reviews-per-day is a plan you can actually finish, because it is sized to the one resource you cannot parallelize.

Cheap parallelism is only cheap when the parallel work does not collide. Two agents editing the same file, or one depending on an interface another has not built yet, turn free throughput into merge conflicts and rework. Managing that comes down to classifying feature relationships during planning:

Isolation is what makes the first case safe and the third case possible; without a worktree per feature, parallel agents share a working tree and every run risks stepping on another. The mechanics of running many isolated agents at once are in the multi-agent coding workflow.

The most common mistake in an agent sprint is committing to the number of features the agents can build rather than the number the humans can review. It is an easy mistake because the build side is visible and fast, diffs appear, cards move, and it feels like progress. But an unreviewed diff is not shipped work; it is a liability sitting in a queue, and merging it unread is how a codebase quietly rots.

So the discipline is to plan to your review capacity. Approving thirty specs in a cycle when your team can carefully review eight diffs a day is not ambition, it is planning malpractice: you have guaranteed a backlog of unreviewed work and a temptation to rubber-stamp it under deadline. The right move is to commit to roughly the number of features your reviewers can clear, hold the rest as a ready backlog, and pull from it as review slots free. A short, fully-reviewed increment beats a long pile of maybe-working diffs every cycle.

When an agent sprint goes wrong, it usually goes wrong in one of four recognizable ways, and each traces back to a planning decision, not an agent one:

AIDEN is built around exactly this shape of planning: a board where a cycle is a set of specs you approve and review, not a pile of points you burn down. It is a cockpit over your existing CLIs, Claude Code and Codex, with BYO inference, so planning sits on top of the agents you already run. Four mechanisms carry the procedure above:

The result is that the planning question this guide argues for, how many well-specified, independently reviewable features can we approve and review this cycle, is the question the board is built to answer. AIDEN is Solo at $19/mo and free for one project, so you can plan a real cycle before committing. Where AIDEN fits alongside a broader planner is covered in project management for AI agents.