Agile Workflows: Scrum and Kanban Integration

Level 4 How-to Updated 2026-10-12

Scrum and Kanban still work when coding agents write most of the code, but the bottleneck moves from typing to specifying and verifying. Refinement turns stories into acceptance criteria an agent can be checked against, sprint planning budgets review capacity instead of implementation hours, a Kanban WIP limit sits on evidence review, and merged pull requests feed the sprint review.

This page is for the tech lead or Scrum Master who runs the ceremonies, and for the developers on the team. The typical situation: the team adopted Claude Code, Codex, or Cursor two sprints ago. Implementation now finishes by Wednesday, yet the burndown flattens because nine pull requests wait for review, two stories came back as “done but not what we meant”, and the sprint review is a scroll through a merge log.

What you’ll walk away with from agent-aware Scrum and Kanban

A ceremony-by-ceremony map of what the agent drafts, what humans decide, and which evidence closes each step.
Board connections for Linear and Jira in Claude Code, Codex, and Cursor, with commands checked against the installed CLIs.
Five copy-paste prompts: story refinement, sprint-capacity check, card-to-plan, sprint-review draft, and retrospective flow data.
A Definition of Done you can adopt as-is, so a story is accepted on evidence rather than on someone reading the diff.
The failure modes of agile-with-agents, each with a recovery step.

What changes in each Scrum and Kanban ceremony?

The ceremonies stay. What moves is the scarce resource: when an agent implements a story in an hour, the constraint becomes how fast the team can say precisely what it wants and prove that it got it. DORA’s AI Capabilities Model names “working in small batches” as one of its seven capabilities (Kevin M. Storer and Derek DeBellis, Google Cloud blog, 2025-09-23); as Nathen Harvey and Allison Park put it, “AI can easily generate massive blocks of code, which are hard to review and test” (Google Cloud blog, 2025-12-10).

Ceremony or flow step	The agent drafts	Humans decide	Evidence that closes it
Backlog refinement	Acceptance criteria, slices, open questions	Scope, priority, which questions block “ready”	Every criterion names the check that proves it
Sprint planning	Capacity check, dependency order	Sprint goal and commitment	Review hours fit the team’s review capacity
Daily work (Kanban flow)	Implementation, tests, board comments	Who reviews what, when to stop a run	CI green and the evidence bundle attached to the PR
Sprint review	Changelog and demo script from merged PRs	What to show, what the product owner accepts	Acceptance tests passing on the release branch
Retrospective	Cycle-time and bounce data per lane	What to change next sprint	A number, not a feeling

Which tickets an agent may take at all, and under how much supervision, is a separate decision covered in shaping a backlog for agents. This page assumes that triage exists and focuses on the ceremonies around it.

Connect the board to your agent

Every prompt below works with pasted ticket text. Connecting the tracker over MCP removes the copy-paste and lets the agent read linked issues and post comments itself. Both Linear and Atlassian run official remote MCP servers over HTTP with OAuth: there is no npm package to install, and the server URLs are the same in every tool. Atlassian recommends https://mcp.atlassian.com/v2/mcp for new setups; the old /v1/sse endpoint stopped being supported after 30 June 2026.

# Terminal, from the repository root (Claude Code 2.1.283)
claude mcp add --transport http linear https://mcp.linear.app/mcp
claude mcp add --transport http atlassian https://mcp.atlassian.com/v2/mcp

Then run /mcp in a session to finish the OAuth sign-in. The default scope is local (this project, only you); add --scope project to share the entry through .mcp.json. Atlassian also ships as a plugin with ready-made skills such as spec-to-backlog: claude plugin install atlassian@claude-plugins-official.

# Terminal (Codex CLI 0.157.1)
codex mcp add linear --url https://mcp.linear.app/mcp
codex mcp login linear
codex mcp add atlassian --url https://mcp.atlassian.com/v2/mcp
codex mcp login atlassian

Codex also has a native Linear integration: you can assign an issue to Codex or mention @Codex in Linear (checked 2026-10-12). Its curated atlassian-rovo plugin still points at the older /v1/mcp/authv2 endpoint (read 2026-09-26), so prefer the direct v2 line above.

Add both servers under mcpServers in .cursor/mcp.json and sign in when Cursor prompts:

{
  "mcpServers": {
    "linear": { "url": "https://mcp.linear.app/mcp" },
    "atlassian": { "url": "https://mcp.atlassian.com/v2/mcp" }
  }
}

Cursor’s marketplace also lists an Atlassian plugin. Per-server scopes and the full tool lists are on Jira and Linear MCP integration and Atlassian MCP.

Refine stories until an agent can be checked against them

Refinement is where agile-with-agents is won or lost. A story that a human developer could interpret sensibly is not enough: the agent will pick one interpretation and make every check it can see pass. The output of refinement is therefore acceptance criteria that each map to a check, slices small enough that one check proves each, and a list of questions only a human can answer. Run this prompt before the refinement meeting, not during it, so the meeting spends its time on the questions.

Read Linear issue ENG-1423 and every issue linked to it. Then read
src/lib/auth/ and app/(auth)/ in this repository. Do not edit anything
and do not write to Linear.

Produce, as Markdown I can paste into the issue:
1. Acceptance criteria as Given/When/Then. For each criterion, name the
   test file or check that would prove it, or write "NO CHECK POSSIBLE"
   and say why.
2. Slices: at most 5, each shippable on its own and provable by one of
   the criteria above. Merge any slice under two hours of work.
3. Open questions a product owner must answer before this is ready.
   Mark each as BLOCKING or NOT BLOCKING.
4. Risk flags: anything touching auth, payments, a schema migration, or
   an external API contract.

Two outputs matter most. A criterion marked “NO CHECK POSSIBLE” means the story is not ready for an agent, whatever its size. A BLOCKING question goes to the product owner, not to the agent’s best guess. How to turn the criteria into failing tests the agent cannot edit is on executable acceptance criteria; the wider spec discipline is on spec-driven development.

Plan the sprint to review capacity, not typing speed

Story points measured how long a human takes to write the code. With agents, the cost that still scales with the story is specifying it and verifying the result. Plan against that.

Measure review capacity. Take the last two sprints and count the agent pull requests each reviewer approved per day. That number, times reviewer-days in the sprint, is your review capacity.
Estimate verification, not implementation. For each slice, estimate the human time to check the evidence, run the demo path, and approve. A slice with strong automated checks costs minutes; one that needs a human to click through three screens costs an hour.
Commit to what fits. Pull slices into the sprint until the verification estimate reaches about 80 percent of review capacity. The remaining 20 percent absorbs rework and bounced runs; adjust it from your own retro data.
Order by dependency. Slices that change a shared contract (an API schema, a database table) go first, so later slices build on merged code rather than on each other’s branches.

Read every issue in the Linear cycle "Sprint 24" for team ENG.
Do not write to Linear.

Our review capacity this sprint is 45 agent pull requests (3 reviewers,
9 days, about 5 approvals per day across the team).

For each issue, list: its slices, the number of pull requests it will
likely produce, and whether each slice's acceptance criteria name an
automated check. Then:
- Total the expected pull requests and compare with the capacity.
- List the issues to drop or defer first if we are over, starting with
  those whose criteria have no automated check.
- Show dependency order: which issues change a shared schema or API
  contract and must merge before others.
Output one table and a short recommendation. No estimates in story points.

The prompt asks for pull-request counts instead of story points on purpose. An agent that invents story points anchors the team on a number it has no basis for; a count of reviewable units is something it can derive from the slices.

Run Kanban flow with a WIP limit on evidence review

On a Kanban board, the agent makes “In progress” fast and fills the column after it. Make that visible:

Split “In progress” into Agent running and Evidence review. The first tracks runs; the second tracks pull requests a human must approve.
Put the WIP limit on Evidence review, not on “In progress”. When the column is full, nobody dispatches a new run; they review.
Add a Needs clarification column before “Ready”. A run that stops on a question or a missing check goes there, not back to “In progress”.

Faros AI’s “AI Productivity Paradox” report (2025) found, as summarised in Faros AI’s own blog coverage (faros.ai, 2025; read via a search extract, not the report itself), that developers on high-AI teams merged about 98 percent more pull requests while pull request review time rose about 91 percent. That is the queue the WIP limit protects.

When a thin card reaches “Ready” anyway, run it through the agent before pulling it:

Read Jira issue SHOP-311 ("Implement social login"). Our stack:
Next.js App Router with Auth.js already wired for email and password in
lib/auth/. We want Google and GitHub providers. Read lib/auth/ first.
Do not write to Jira yet.

Draft, as Markdown for the card:
- A two-sentence scope statement: what is in, what is out.
- A checklist of at most 8 items (provider config, callback routes,
  account linking, UI buttons, environment variables, tests).
- Acceptance criteria as Given/When/Then, each naming its test.
- Open questions, for example whether a Google login links to an
  existing email account.
Show me the draft. After I reply "apply", add it to SHOP-311 as a
comment and change nothing else on the issue.

The last two lines are the pattern for every board write: the agent drafts, a human says “apply”, and the write is scoped to one named issue.

Who updates the board: automation in Claude Code, Codex, and Cursor

The MCP connection is identical in shape across the three tools. What differs is who drives board updates once a run finishes and how that run is triggered.

Interactive sessions start in auto mode from v2.1.283 (both release channels on 2026-10-12) unless your model or settings keep Manual, so start board sessions with --permission-mode manual: every MCP call not in your allow rules then asks first. Allow-list the Linear and Atlassian read tools if you like, and keep the write tools out. For scheduled work, a routine (/schedule, research preview) can run a sprint-end prompt as a cloud session; see Claude Code routines. The scripted pattern that needs no board credentials is to draft in -p mode and let a human post the result, as in the sprint-review command below.

The native Linear integration lets the team assign an issue to Codex or mention @Codex on it (checked 2026-10-12). Assign only issues your triage marked for background work, never the whole inbox. Setup and limits are on Codex in Slack and Linear.

The full intake-to-pull-request automation, including the permissions an unattended run needs, is on the issue-to-PR pipeline.

Draft the sprint review from merged pull requests

Pull the sprint’s merged pull requests into a file first, then give the agent read-only access to that file. The agent never needs a token or network access, and the input is exactly what shipped.

# Terminal, from the repository root, with the GitHub CLI signed in
gh pr list --state merged --search "merged:2026-09-14..2026-09-25" \
  --limit 200 --json number,title,body,labels,url > sprint-24-prs.json

# -p sessions do not start in auto mode; only Read is allowed here
claude -p "$(cat sprint-review-prompt.txt)" \
  --allowedTools "Read" --output-format text > sprint-24-review.md

# read-only sandbox; the final message is written to the file
codex exec -s read-only -o sprint-24-review.md "$(cat sprint-review-prompt.txt)"

Paste the prompt below into the agent with sprint-24-prs.json attached, or run it from a scheduled or Linear-triggered automation.

Save this prompt as sprint-review-prompt.txt:

Read sprint-24-prs.json. It lists every pull request merged in Sprint 24.
Use only what is in that file.

Produce:
1. A changelog grouped as Added / Changed / Fixed, written for a product
   owner who does not read code. One line per user-visible change; cite
   the pull request number on each line.
2. A demo script of at most 8 steps covering the sprint goal's happy path
   and one failure path.
3. A "Before release" list: any pull request whose body mentions a
   migration, a new environment variable, or a feature flag.
4. A "Missing evidence" list: any pull request whose body has no test
   results or acceptance-criteria checklist.
Do not invent changes that are not in the file.

The “Missing evidence” list is the useful part for the review meeting: it tells the product owner which stories were merged without the proof the Definition of Done asks for.

Bring flow data to the retrospective

The retrospective stays a human conversation, but it should start from numbers. Ask the agent to compute them from the board rather than from memory.

Read every issue completed in the Linear cycle "Sprint 24" for team ENG,
with its status history. Do not write to Linear. If the tool cannot
return status history, say so and stop instead of estimating.

Compute, and show as one table per question:
1. Cycle time (In progress to Done) per issue, and the median for issues
   labelled lane:background versus lane:interactive.
2. Time each issue spent in "Evidence review".
3. Bounces: issues that moved back from "Evidence review" or "Done" to an
   earlier column, with the comment that explains why, if any.
4. Issues that entered "Needs clarification", and what question stopped
   them.
End with the three issues that waited longest in review, and nothing
else. No recommendations; the team will discuss them.

The labels lane:background and lane:interactive come from the triage on shaping a backlog for agents; replace them, and the column names in the prompt, with your own. Metric definitions that hold up across sprints are on lifecycle metrics.

How do you know the sprint’s agent work is right?

Nobody on the team reads every line the agents wrote, so acceptance rests on evidence that machines produce and a named person checks. Adopt this Definition of Done for any story an agent implemented:

Every acceptance criterion maps to a named test, and the tests were written and approved before implementation. They live in paths the implementing run cannot edit (protecting the oracle).
CI is green: type check, lint, unit and acceptance tests on the merge commit.
The pull request carries an evidence bundle: the criteria checklist with a result per line, test output, and a screenshot or recording for anything user-visible.
An agent reviewer has run, and a human reviewed its findings and the evidence. Changes to auth, payments, migrations, or public API contracts escalate to a human code read (evidence, not diffs).
The product owner accepts the story at the sprint review against the acceptance tests passing on the release branch, not against the demo alone.

Sign-off is split. The developer who owns the ticket approves the evidence and merges. The product owner accepts the increment. The tech lead owns the WIP limit and decides when a task class moves between lanes.

What breaks when agents join a Scrum or Kanban team?

Review becomes the sprint’s hidden queue. Implementation finishes early and the burndown stalls. Recovery: move the WIP limit to Evidence review and stop dispatching new runs while it is full; plan the next sprint to measured review capacity.
Agent estimates become the team’s anchor. Story points the agent invents shape the planning discussion. Recovery: never ask an agent for points; ask for slices and pull-request counts, and let the team size verification effort.
Over-decomposition. A story comes back as 14 subtasks, half of them “create the file”. Recovery: cap slices in the prompt (the prompts above use 5 and 8) and require each slice to map to a check.
The wrong ticket moves. With Linear, Jira, and GitHub all connected, “move the ticket” hits the wrong board or issue. Recovery: name the system and the key in every prompt (“Linear issue ENG-1423”), use the draft-then-apply pattern, and restore the status from the issue’s history.
Ticket text steers the agent. Anyone who can edit an issue can plant instructions in it. Recovery: dispatch only tickets a trusted team member labelled, treat ticket bodies as data, and give runs no production credentials. See MCP security.
The card drifts from the code. Implementation shows the refined plan was wrong, but the card still says the old thing. Recovery: update the acceptance criteria and the card in the same pull request that changes the behaviour, and treat a mismatch at sprint review as a bounce.

Where to go next with agile and agents

The artifact chain: the intent, spec, plan, and task sequence each story runs through once it leaves the board.
Executable acceptance criteria: turn refinement output into failing tests before the agent starts.
Shaping a backlog for agents: eligibility, lanes, and a ticket template for agent work.
Behavior-driven development workflows: Given/When/Then scenarios as executable specifications.
The BMAD Method: agile roles run as agents, and when that ceremony overhead pays off.