AIDLC With Scrum and Kanban
AIDLC does not replace a process framework. It runs inside one. This page maps the five phases onto the Scrum events and a Kanban board, and changes only what agent-written code forces to change: how work is estimated, how capacity is planned, and what "done" means.
AIDLC Runs Inside Your Framework
Scrum and Kanban organize a team's time and flow of work. AIDLC describes the life of a change: what to analyze, how to design it, how to build it with agents, how to ship it, and what to learn afterward. The two are not alternatives. A team keeps its sprint cadence or its board and puts the five phases to work inside it.
What changes is the load on each step. When agents write much of the code, authoring gets cheap and everything around it gets relatively expensive: defining the work precisely, reviewing the result, and proving it is correct. A process that was tuned for the speed of human typing needs three adjustments, and this page covers each in turn - estimation, capacity, and the Definition of Done - plus the Kanban board settings that make the same points visible.
Mapping the Five Phases to Scrum Events
The mapping is approximate by design: phases describe a change, events describe a team's rhythm, and one sprint holds many changes at different phases.
| Scrum event | AIDLC phase | What changes with agents |
|---|---|---|
| Backlog refinement | Analyze and Ideate | Items are refined into a ticket contract: risk tier, acceptance criteria, data touched, rollback plan, and out-of-scope. A vague item is the most expensive input an agent can receive. |
| Sprint planning | Ideate | The team chooses work against review capacity, assigns a lane (A or B), and approves plans for risky items before implementation starts. |
| The sprint | Develop and Launch | Agents draft, humans review, tests gate the merge, and small batches reach production behind flags. The daily sync watches the review queue first. |
| Sprint review | Launch | Stakeholders inspect working software. The Scrum Guide states the purpose as "to inspect the outcome of the Sprint and determine future adaptations." |
| Retrospective | Curate | Escaped defects and review friction become new rules, skills, and instruction-file edits through the learn loop. |
The Scrum Guide (November 2020) frames Sprint Planning around three topics: why the Sprint is valuable, what can be Done this Sprint, and how the chosen work will get done. Each one gets sharper with agents. "Why" is unchanged. "What can be Done" is limited by verification, not authoring. "How" now includes which items go to which lane and which work class.
Estimation When Agents Write the Code
Estimate the cost of being sure, not the cost of typing. If an agent can draft a change in minutes, an estimate built on how long it takes a person to write it measures the wrong thing. The durable costs are understanding the problem, reviewing the diff, strengthening the tests, and releasing safely.
Relative sizing still works, and it is still the better tool, because it compares items to each other instead of to a clock. What teams should recalibrate is the reference story. Re-point the team's baseline items by asking what it would take to verify them: how many files a reviewer must read, how much of the behavior is covered by tests that would actually fail, how risky the risk tier is, and how clear the acceptance criteria are.
Two items of equal authoring effort can differ widely in verification effort. A copy change and a change to money math may both take an agent a few minutes. The first needs a glance; the second needs a senior reviewer, a plan approved up front, and tests scored by mutation. Size reflects that gap. Where the team skips this step, sprints overcommit on cheap-to-write, expensive-to-verify items and discover the bill at review.
Plan Around Review Capacity, Not Authoring Capacity
In a traditional sprint, the team's authoring hours set the limit. With agents, authoring is no longer the scarce resource: reviewer attention is. DORA's 2026 ROI of AI-assisted Software Development report names the effect the verification tax - the review and validation cost that AI shifts onto humans. The productivity paradox page covers the evidence, and the glossary entry gives the short definition.
Practically, sprint planning starts with a question about reviewers: how many tier-appropriate review hours exist this sprint, and how much of that does already-open work consume? Commit only to what that budget can absorb. Agents will happily produce more than the team can check, and an unchecked change is a debt, not a delivery.
Three habits keep the plan honest. Cap pull request size so each review stays tractable. Hold a share of the sprint back for review of work started last sprint and for incident follow-up. And look at the ratio between work started and work merged: when it climbs, the team is outrunning its reviewers and the next sprint should plan fewer starts, not more.
The Ticket Contract in Refinement
Refinement is where most of an agent's success is decided. The ticket contract template turns a refined item into something an agent can act on and a reviewer can check against: a risk tier, a lane, the data classification touched, acceptance criteria written as Given/When/Then, a data contract, a rollback plan, a blast radius, and an explicit out-of-scope list.
Make the contract part of the team's Definition of Ready. An item that lacks a tier or acceptance criteria is not ready to enter a sprint, however small it looks. The extra refinement minutes are cheaper than the review cycles an ambiguous ticket produces, and the same fields later supply the evidence pack for the release.
Kanban: WIP Limits, an Agent Lane, and Classes of Service
The Kanban Guide (2025 edition) defines work in progress as "the number of work items started but not finished" and has members control it. Agents make that control matter more, because starting work is now nearly free.
A WIP limit on the review column
Set the limit on the column that holds items awaiting review, not on the "in development" column. When the review column is full, agents stop starting new work and the team swarms on reviews. The limit is the mechanism that keeps authoring from outrunning verification.
An agent lane
Add a swimlane for tickets labeled agent-eligible, which is Lane B. It makes unattended work visible, gives it its own WIP limit, and lets the team see at a glance how much of the board the agents hold.
Work classes as classes of service
The work classes map naturally to classes of service. Test backfill and dependency bumps can flow unattended through the agent lane. Money math, auth, and external adapters get a human-in-the-loop class with a senior reviewer.
Flow metrics then carry the signal. Watch how long items wait in the review column and how many reopen after merge; a short cycle time with a growing reopen count is the board's version of the verification tax.
Retrospectives Feed the Learn Loop
The Scrum Guide gives the Sprint Retrospective one purpose: "to plan ways to increase quality and effectiveness." For an agent-assisted team that plan has concrete outputs. Every escaped defect becomes a review rule; every repeated task becomes a versioned skill; every confusing agent result becomes an edit to the instruction file. This is the learn loop, and the retrospective is the natural meeting to run it.
Bring evidence rather than impressions: review latency, defects that escaped, items that bounced between agent and reviewer, and the changes where the agent's plan was rejected. Close each retrospective with owners for the rule, skill, and instruction edits, and check at the next one whether the defect class repeated. The measuring impact page covers which baselines make that comparison meaningful.
Anti-Patterns
Velocity inflation
What it looks like: Story points per sprint climb because agents finish items faster, and the climb is reported as productivity.
The fix: Pair velocity with quality signals - escaped defects and change failure rate - as in The Productivity Paradox.
Points per agent
What it looks like: Points, tickets, or pull requests are credited to each agent and compared, as if the agent were a team member with a quota.
The fix: Measure team outcomes. An agent is a tool in the team's pipeline; the output belongs to the team and its reviewers.
Sprint stuffed by agents, review starved
What it looks like: The sprint holds twice the items, all drafts are ready by midweek, and the last day is a rush of shallow approvals.
The fix: Plan against review capacity and cap the review column. This is the Era 3 tooling on Era 2 process pattern in sprint form.
Where It Fits in AIDLC
This page is the process wrapper around all five phases. Refinement lives in Analyze and Ideate, the sprint itself in Develop and Launch, and the retrospective in Curate. The worked example shows one change moving through them, Teams and Skills covers who does what, Legacy Code covers adopting agents in inherited codebases, and AIDLC vs the ML Lifecycle covers teams whose product contains a model.
Frequently Asked Questions
No. Scrum organizes a team's cadence and accountability; AIDLC describes the life of a change from analysis to curation. AIDLC runs inside Scrum or Kanban, with refinement, planning, the sprint, review, and retrospective each doing the work of one or two phases.
Estimate verification and review effort, not typing. Relative sizing still works, but re-point the reference items by what it takes to prove a change correct: files to review, strength of the tests, risk tier, and clarity of the acceptance criteria. Then plan the sprint against review capacity rather than authoring capacity.
A named human reviewer, an assigned risk tier, tests that pass the team's mutation-score bar, the ticket ID in the commits, and updated docs and instruction files. Add these to the team's single Definition of Done so agent-authored and human-authored changes meet the same standard.
Keep Your Process, Move the Bottleneck
Start with the ticket contract and a WIP limit on review, then let the retrospective tune the rest.