Sprint planning runs forty-five minutes long because half of it is the team reading a vague story together and guessing at subtasks. Then the cards that come out of it land in “To Do” with a one-line title and no acceptance criteria, so whoever picks them up burns the first hour reverse-engineering what was meant. AI agents are good at exactly this connective tissue — decomposing a story into tasks, fleshing out a card, drafting the review changelog — and with an MCP connection to your board, they can do it without you copy-pasting between tools.
This guide shows how to fold an AI agent into Scrum ceremonies and Kanban flow with concrete prompts and real board integrations, not “AI makes the team faster” platitudes.
An AI agent can contribute to every phase of a sprint, but only if you give it the real artefacts (the story, the repo paths, the merged PRs) rather than a summary.
Sprint Planning
Feed the agent a user story plus the relevant repo paths and have it propose a subtask breakdown with rough estimates and risk flags. You’re not outsourcing the estimate — you’re starting the conversation from a concrete decomposition instead of a blank board.
The Sprint Itself
Developers pull a task and implement with the PRD → Plan → Todo and TDD loops. The board integration closes the loop by moving the ticket as the work progresses.
Sprint Review
Generate the review changelog from the actually-merged PRs in the sprint. The agent reads the PR titles and bodies and drafts user-facing release notes and a demo script — minutes instead of a half-hour of scrolling.
Retrospective
The retro stays human, but bring data: ask the agent to summarize cycle-time per card from the board, so “we were slow on the API work” becomes a number instead of a vibe.
The highest-leverage prompt is the one that turns a story into an estimable plan. Be specific about your stack so the subtasks are real, not generic.
With the Atlassian or Linear MCP connected (below), the agent can pull those merged PRs and their linked issues itself instead of you pasting numbers.
Kanban is about flow and short cycle time. The agent’s job is to remove the friction at the edges of the board: the underspecified card on the way in, and the manual status-shuffling on the way out.
A card titled “Implement social login” tells the implementer almost nothing. Run it through the agent before pulling it.
Before: Implement social login — no scope, no criteria, no idea if account-linking is in scope.
After: a card with a scope statement, an eight-item checklist, three Given/When/Then criteria, and two flagged questions (“link to existing email accounts, or separate?”). The implementer starts coding instead of guessing, and cycle time drops because the ambiguity got resolved before the card entered “In Progress.”
To let the agent read and move tickets, connect a board MCP server. Both are remote MCP servers added over the HTTP transport — there is no @linear/* or @jira/* npm package to install.
MCP setup is identical in shape across the three tools; only the registration command differs. For Claude Code:
# Linear (first-party remote MCP)claude mcp add --transport http linear https://mcp.linear.app/mcp
# Atlassian — Jira + Confluence (official remote MCP)claude mcp add --transport http atlassian https://mcp.atlassian.com/v1/mcpBoth use OAuth on first connect — you authorize in the browser, no API token in a config file. In Cursor and Codex you register the same two URLs through their MCP config UI/file; the endpoints and scopes are the same. See the Atlassian MCP and project-management MCP guides for the per-tool config and the full tool list each server exposes.
Before MCP: you copy the ticket text into the agent, do the work, then switch to Jira/Linear to move the card and paste a summary.
After MCP: “Move LIN-204 to In Review and comment with a 3-bullet summary of the change” happens in the same session, against the live board.
Where the work actually diverges is who drives the board move — and this is a genuine three-tool difference, not an “identical” case.
Use agent mode with the board MCP to pull a ticket into the IDE: “Read LIN-204 from Linear and scaffold the work.” For hands-off runs, a background agent can take a ticket, implement against the checklist, and report back. Cursor’s strength is the human-in-the-loop IDE pull — you stay in the editor and the ticket context comes to you.
Claude Code shines as a scripted/headless step in CI. Run claude -p non-interactively with the board MCP available so a post-merge job comments the changelog on the ticket and moves it to “In Review.” Scope it tightly with --allowedTools (e.g. Bash, Edit) so the automated step can run and patch but nothing else. This is the “robot teammate that updates the board” pattern.
Codex leans on its native integrations and automations: connect GitHub, Slack, and Linear, then have Codex move the card, open the PR, and post to the team channel as part of one task — including from Codex Cloud for longer unattended runs. When the board work is “react to a GitHub/Slack event and update Linear,” Codex’s built-in connectors do it without a custom MCP wiring step.