AI sprint planning: what actually works in 2026

Sprint planning has two jobs stapled together: preparation, getting the backlog into a state where decisions are possible, and decision, choosing what the team commits to. AI is genuinely good at the first job and should be kept away from the second. Most of the "AI sprint planning" disappointment we hear about comes from teams that got this backwards.

flowchart LR
    B[Raw backlog] --> P[Preparation, AI drafts]
    P --> M[Planning meeting, humans decide]
    M --> S[Committed sprint]

We run our own product this way, sprints planned in Utter with agents doing the preparation, so what follows is the split that has actually held up, including the parts where the AI is not the answer.

What does AI do well in sprint planning?

Backlog grooming, the part everyone skips. The classic planning meeting starts with a backlog nobody groomed: duplicate tickets, bugs with no reproduction steps, stories missing acceptance criteria, estimates from a different era. An agent that sweeps the backlog the day before turns the first thirty minutes of planning into five. In the sweep it:

• flags duplicates and stale issues
• drafts missing acceptance criteria for a human to approve
• points at issues whose descriptions contradict their comments

This is the same mechanism as AI triage, pointed at the backlog instead of the intake queue.

First-pass sizing. An agent that has read your history can propose estimates with reasons: "similar to WEB-180 and WEB-195, both landed at 3 points." The proposal is not the estimate, the team's reaction to it is. But anchoring the conversation on a reasoned draft is faster than planning poker from silence, and it drags the outliers into the open. The ticket the agent calls a 2 that your senior calls an 8 is exactly the ticket that needed discussion.

Capacity arithmetic. The un-fun math, who is on leave, how many points did we really finish the last three sprints, does the proposed set fit, is mechanical, and models plus your velocity reports do it without flattery. Utter's velocity and burndown reports feed this directly; the agent reads them over the same MCP server your other tools use. If your agent talks REST instead, the whole capacity input is one GET:

curl "https://utter.ae/api/v1/workspaces/acme/projects/WEB/reports/velocity?period=90d" \
  -H "Authorization: Bearer $UTTER_API_KEY"

import os
import requests

r = requests.get(
    "https://utter.ae/api/v1/workspaces/acme/projects/WEB/reports/velocity",
    params={"period": "90d"},
    headers={"Authorization": f"Bearer {os.environ['UTTER_API_KEY']}"},
)
velocity = r.json()["data"]["data"]  # unit, average, bars

The response is one bar per recent sprint, committed vs completed, plus the average (trimmed here):

{
  "data": {
    "report": "velocity",
    "data": {
      "unit": "count",
      "average": 11.5,
      "bars": [
        { "sprintName": "Sprint 14", "status": "completed", "committed": 14, "completed": 12 },
        { "sprintName": "Sprint 15", "status": "active", "committed": 13, "completed": 4 }
      ]
    }
  }
}

Drafting the sprint goal. Given the candidate issues, an agent writes a competent one-sentence goal. Competent is the ceiling; if the goal matters, a human sharpens it. If the drafted goal comes out mushy, that is usually the plan's fault, not the model's, which makes it a useful smoke alarm.

Executing within the sprint. Once the sprint exists, coding agents on the board can carry real items: assign the well-scoped bugs to a named agent, watch its sessions run on the tickets, review its output like anyone else's. Planning with agents in the roster means some capacity is agent capacity, and the plan can say so explicitly.

What should AI not decide?

What the team commits to. Commitment is a promise made by the people who will keep it. A model has no skin in that promise and no knowledge of half the things that bend it, the reorg rumor, the flaky dependency, the teammate who is quietly burned out. Let the agent propose a sprint that fits capacity; let humans strike and swap until it is theirs. A committed-by-AI sprint fails socially before it fails technically: when it slips, nobody feels responsible, because nobody decided.

Priority calls between stakeholders. "Support wants the export bug, sales wants the SSO ticket, we can do one" is a negotiation, not an optimization. The agent's job is making the trade visible early, not making it.

Anything that punishes people via metrics. The same velocity data that powers capacity checks can be misused as a leaderboard. Do not wire AI summaries to individual throughput. It poisons the estimates within two sprints, because people start estimating defensively, and then the AI's capacity math is garbage too.

A working setup, step by step

This is the loop we actually run, on stock Utter parts:

flowchart LR
    G[Groom sweep, day before] --> Z[Sizing pass, day before]
    Z --> P[Planning, 30 min, humans]
    P --> A[Assign, agents included]
    A --> D[Daily digest watches drift]

1. T-1 day, the groom sweep. A named agent sweeps the backlog: flags duplicates and stale issues, drafts missing acceptance criteria as comments (drafts, not silent edits), and labels candidates that match the coming sprint's theme. Its changes are attributed in the activity log like any member's.
2. T-1 day, the sizing pass. The agent proposes estimates on unestimated candidates, each with its reasoning in a comment. Humans accept or argue in the morning. If the agent pulls candidates itself, that is a plain issue query, GET /issues?status=backlog scoped to the project.
3. Planning, 30 minutes, humans. The board shows groomed, sized candidates and a capacity line from the velocity report. The team argues about the top of the list, strikes what does not fit, swaps what support escalated, and commits. The agent is silent in this meeting.
4. Immediately after: assignment, including agents. Well-scoped items go to coding agents as named assignees; ambiguous items go to humans. Agent sessions are visible on each ticket, so mid-sprint, "how is the agent doing" is a glance, not an interrogation. Status handoffs between agents follow the pattern we described here.
5. Mid-sprint, the digest watches. The daily AI digest reports scope changes, stuck items, and agent sessions in "blocked", so drift is visible on day 3, not at the retro.

Nothing in this loop requires believing AI is magic. Every AI output is a draft or a flag; every decision has a human name on it; everything is attributed on the board.

What changes after a few sprints

Two effects showed up for us and for teams we have compared notes with. First, planning gets shorter, not because anyone rushes, but because the meeting stops doing preparation. Thirty minutes is realistic for a team of eight once grooming and sizing arrive pre-drafted.

Second, and less expected, estimate quality improves: when a model proposes sizes with visible reasoning, humans correct it out loud, and that standard of "say why" leaks into how people estimate everything.

What does not change: bad backlogs still make bad sprints. An agent can flag that a story has no acceptance criteria; it cannot know what the customer actually needs. AI sprint planning is a preparation upgrade, not a substitute for knowing what you are building.

If you want to run this loop on your own backlog, every new Utter team gets 14 days of Pro free, no card: sprints, velocity reports, the digest, and named agents are all in the box.