TL;DR
Sprint planning is two jobs: deciding what matters (yours) and sequencing it under a capacity ceiling (mechanical, error-prone, and exactly what an LLM does well). Give a chat model — GPT-5.5 Thinking, Claude Opus 4.7, or Gemini 3.1 Pro — your backlog in dev-days, your real capacity, one sprint goal, and your anti-goals. It returns a committed list under the ceiling, a critical path, two standup risks, and a Friday demo script. You keep the estimating and the final commit. The prompt below does the whole thing; the tool table at the bottom covers when to switch from a chat window to Jira Rovo or Linear.
The task
You run a small product team. Sprint planning eats a half day every two weeks, and most of that half day is not thinking — it is adding up dev-days, untangling which item blocks which, and re-checking that you did not quietly commit to 130% of capacity again. That arithmetic is the part AI should own, so the half day collapses into 20 minutes of you making the genuinely hard calls.
What AI cannot do: tell you that the export feature matters more than the search refactor. That is a judgment call about your customers, and it stays yours. What it can do, reliably, is take your priorities and your estimates and produce a sequence that respects dependencies and the capacity ceiling — then surface the two risks you would otherwise discover in week two.
When this is the right job for AI
- You have a real backlog (concrete items, not “we should do X someday”).
- You can give estimates in dev-days, not story points. Story points are an abstract velocity unit; LLMs reason far better over a concrete “4d” than over “5 points,” because dev-days sum directly against a dev-day capacity ceiling.
- You will own the final commit. AI proposes a sequence; you decide what ships.
What to feed the AI
- Backlog: 10–25 items, each one line of description plus a dev-day estimate.
- Sprint length + capacity in dev-days. Compute it explicitly, e.g.
10 working days × 3 devs = 30 dev-days; subtract 1 day each for review and 1 day for on-call = 24 dev-days available. - Sprint goal: one sentence (“stabilize search and ship export to beta”).
- Known dependencies (“export needs the search index refactor first”).
- Anti-goals (“do NOT start the agentic-eval rewrite”). Anti-goals are roughly half of real sprint planning — a backlog tells AI what could happen; anti-goals tell it what must not.
Copy-ready prompt
This works as-is in any frontier chat model. For the cleanest dependency reasoning, use a thinking mode: GPT-5.5 Thinking, Claude Opus 4.7, or Gemini 3.1 Pro.
You are sequencing a 2-week product sprint. You do NOT estimate effort —
use only the dev-day numbers I provide. Your job is sequencing under a
capacity ceiling and surfacing risk.
Goal: stabilize search and ship the export feature to beta.
Anti-goals: do NOT start the agentic-eval rewrite.
Team capacity: 24 dev-days available across 3 engineers.
Hard rule: the committed list must total <= 90% of capacity (<= 21.6
dev-days). Reserve the rest as buffer.
Backlog (one-line + dev-day estimate):
1. Search index refactor — 4d
2. Export-to-CSV V1 — 3d
3. Export-to-PDF V1 — 5d (depends on 2)
4. Fix search ranking edge cases — 2d
5. Beta-flag wiring for export — 1d
6. Beta user comm email — 0.5d
7. Migration script for export schema — 2d
8. On-call training doc update — 1d
9. Two known P1 bugs in search — 1.5d total
10. Spike: agentic-eval rewrite scoping — 2d
... [paste more]
Output, in this order:
1. The critical path: the chain of items that must complete in sequence.
2. A committed sprint list with total dev-days (must be <= 21.6).
3. A "not this sprint" list, each with one line of reasoning.
4. Two risks to flag in standup tomorrow. Each must name a specific item
and what slipping it would break.
5. The Friday-of-week-2 demo script: 3-4 things to show, in order.
6. The one item I'll be tempted to add mid-sprint that I should reject.Sample output structure
Critical path: search refactor → migration script → export CSV → beta flag → export PDF.
Committed sprint (21.5 dev-days of 24, buffer 2.5):
- Search index refactor (4d)
- Fix search ranking edge cases (2d)
- Two P1 search bugs (1.5d)
- Migration script for export (2d)
- Export-to-CSV V1 (3d)
- Beta-flag wiring (1d)
- Beta user comm email (0.5d)
- On-call training doc (1d)
- Export-to-PDF V1 (5d)
- Buffer / review (1.5d)
Not this sprint:
- Agentic-eval rewrite scoping (2d): excluded per anti-goal.
Risks for standup tomorrow:
- Export PDF depends on CSV; if CSV slips by 1 day, PDF won’t demo Friday.
- Search refactor is estimated at 4d; if it runs to 6d, the migration script slot disappears and CSV starts late.
Friday demo script:
- Show the search ranking fix on the 3 test queries that were broken.
- Show new export-to-CSV in the beta-flagged tenant.
- Walk through migration-script results in staging.
- (Stretch) show the PDF export prototype.
Tempted to add but won’t: “let me just sneak in the agentic-eval spike.” Reject — it is the explicit anti-goal.
Fixing a bad first draft
The model almost always returns a usable plan on the first pass; the failures are predictable, and each has a one-line correction you paste back:
| What went wrong | Why it happens | The fix to paste back |
|---|---|---|
| Committed list hits ~100% of capacity | LLMs are eager; they fill the ceiling | ”Re-do. Committed list must be <= 90% of capacity. Show the buffer line.” |
| Dependencies ignored (PDF before CSV) | It optimized for dev-day packing, not order | ”List the critical path as an ordered chain before the committed list.” |
| Vague risks (“scope might grow”) | No grounding requirement | ”Each risk must name one specific backlog item and what slipping it breaks.” |
| No demo, or a demo of half-finished work | It treated the demo as optional | ”Every demo item must be a thing a stakeholder can watch run end to end. If nothing qualifies, the sprint plan is wrong — re-sequence.” |
| It re-estimated your items | You left the door open | Keep the “you do NOT estimate effort” line in the prompt; it is load-bearing. |
Cross-team dependencies
When an item waits on another team, do not let AI guess the date. Add the committed date to the dependencies line: Export schema migration — blocked until Platform team ships the new column (committed Thu wk1). The model then sequences your team’s work around that fixed point instead of inventing a plausible-but-wrong slot. If the other team has not committed a date, that item is not plannable this sprint — flag it as a risk, not a commitment.
Chat window vs. a tool with this built in
A chat prompt is the fastest path and costs nothing beyond your existing subscription. Move to a dedicated tool when the backlog lives in an issue tracker and re-typing it is the bottleneck. As of June 2026:
| Approach | What it does for planning | Cost (individual / per seat) |
|---|---|---|
| Chat model (GPT-5.5 Thinking / Claude Opus 4.7 / Gemini 3.1 Pro) | You paste the backlog; full control of the prompt above. Best for the sequencing + risk + demo job. | ChatGPT Plus $20/mo · Claude Pro $20/mo ($17 annual) · Google AI Pro $19.99/mo |
| Jira + Rovo (Atlassian Intelligence) | Drafts user stories and acceptance criteria, a “Readiness Checker” agent flags backlog items missing fields, and Rovo writes the stakeholder sprint summary. AI is bundled into paid Jira; Premium includes 70 Rovo credits/user/month. | Jira Premium ~$15.63/user/mo (AI included) |
| Linear (Agent + Triage Intelligence) | Semantic duplicate detection on issue creation, AI-routed triage, and auto-generated weekly project summaries you can forward to stakeholders. AI agents are on every plan; Triage Intelligence + Insights need Business. | Free $0 (Agent beta) · Business $16/user/mo annual |
Sources for the table: Atlassian — Rovo in Jira, Linear pricing.
The honest split: Rovo and Linear are good at the writing and hygiene around planning (drafting tickets, catching missing fields, summarizing for stakeholders). Neither replaces the sequencing-under-a-ceiling judgment the prompt above forces — for that, the explicit chat prompt still wins because you control the capacity rule and the anti-goals.
Common mistakes
- Asking AI to “prioritize” with no anti-goals. Without them the model maximizes throughput and happily schedules the one thing you told the team to avoid.
- Letting AI estimate effort. Estimates encode context only your team has. AI sequences what you provide; it does not invent dev-days.
- Filling 100% of capacity. A sprint planned to the ceiling overruns the first time anything is harder than estimated. The 90% rule is the buffer.
- Shipping a sprint with no demo. If nothing lands a watchable demo by Friday, the next plan you write has no credibility.
FAQ
- Which model should I use? Any frontier model in a thinking mode handles this. The hard part is multi-step dependency reasoning, where GPT-5.5 Thinking, Claude Opus 4.7, and Gemini 3.1 Pro all do well. Pick whichever you already pay for; the prompt is identical.
- Our team uses story points, not dev-days. Now what? Convert to dev-days for the prompt only (a rough hours-per-point factor is fine), then translate the committed list back to points for your board. LLMs reason much better over dev-days because they sum directly against capacity.
- Can AI run the actual standup? No, but it can turn standup notes into a “burnup vs. plan” delta — what is ahead, what is behind, what is now at risk. That is a separate, daily prompt, not part of sprint planning.
- Does Jira or Linear do this automatically now? Partly. As of June 2026, Jira Rovo and Linear draft tickets, flag incomplete backlog items, and summarize sprints for stakeholders, but neither commits a capacity-bounded, dependency-ordered plan for you. They handle the hygiene; the sequencing call still runs through a prompt like the one above.
- How much should I trust the dev-day total it reports? Verify the arithmetic yourself — models occasionally mis-sum a list. The total is the one number you should re-add by hand before committing.