How to use AI for sprint planning without handing over the commitment

What can AI actually do inside a sprint planning session?

Three jobs, and the commitment is not among them. A model can draft a candidate sprint plan from a pasted backlog, it can flag ordering conflicts between items that touch the same service or the same person, and it can read a thin ticket and produce the questions somebody has to answer before that ticket is allowed into a sprint. The Scrum Guide timeboxes Sprint Planning at a maximum of eight hours for a one month Sprint, and most teams burn the first chunk of that reading items out loud that nobody has looked at since they were written. That reading is the part a model absorbs in seconds.

The limit is sharper than it sounds. The Scrum Guide puts item selection with the Developers, and ties their confidence in a forecast to three things they know and a model does not: their past performance, their upcoming capacity, and their Definition of Done. Feed all three in and the draft gets better. It still will not know that the person who owns the billing service has been on call for nine nights, or that the team has silently agreed the search rewrite is cursed.

What do you have to paste in before the draft is worth reading?

A plan is only as honest as its inputs, and the input people skip is availability. Here is the minimum set.

Input	What it looks like	What breaks without it
Candidate items	Full ticket text, not just titles	The model sizes work off a five word summary
Sprint dates	Start, end, and any public holiday	Two lost days vanish from the plan
Availability	Person by person, in days, including on call and leave	The plan assumes a full team
Sprint goal	One sentence naming the outcome	Every item looks equally in scope
Recent history	Items finished in the last 2 or 3 sprints	No reference point for what this team gets done
Known constraints	Frozen deploys, dependent teams, review bottlenecks	Sequencing that cannot physically happen

Atlassian's own planning material makes the same point from a different direction: capacity is a resourcing question, not a ticket counting question, and it changes sprint to sprint. State it explicitly or the draft quietly assumes a team of clones with no meetings.

A worked example: 16 candidate items, a 10 day sprint, one missing person

Take a real shape. Sixteen candidate items, a 10 working day sprint, four engineers, one of whom is on support rotation for the first week and another who is out for three days. The last three sprints closed 11, 9 and 14 items respectively, with the 14 inflated by a batch of copy changes.

Paste that in and ask for four things in order: a proposed sprint scope with each item mapped to the sprint goal, a list of items the model would leave out and why, a dependency graph in plain sentences, and a list of every item whose description is too thin to size. What comes back is usually a scope of 10 to 12 items, a sensible complaint that three tickets are unwritable as stated, and two or three dependency claims.

That last output is where the value concentrates. A model reading all 16 descriptions at once notices that the "add export to CSV" item and the "new reporting filters" item both describe changing the same query builder, which means whoever picks up the second one inherits a merge conflict and a retest. Two humans reading tickets in sequence, in a meeting, at 4 PM, routinely miss that.

Where does the dependency spotting actually earn its keep?

Cross team edges, not internal ones. Your own engineers usually know their codebase well enough to catch overlapping work inside one service. What they do not reliably catch is the item whose acceptance criteria quietly depend on a migration another squad has not scheduled, or the third ticket in a sprint that needs the same design review from the same person in the same week.

Ask for the claim and the evidence together. A useful instruction is: for every dependency you assert, quote the item ID and the exact sentence that made you think the two are linked. A dependency the model cannot quote is an invention, and inventions are easy to throw away once they arrive with their sources attached. This is the same discipline that makes backlog refinement tolerable at volume, and the same reason a drafted plan should always be read as an argument rather than an output.

What goes wrong: the plausible plan that ignores a person

The failure is not hallucinated tickets. It is a plan that reads beautifully and cannot be delivered by the people in the room.

A team pastes in its backlog and gets a sprint that puts three payments items together, sequenced correctly, with clean acceptance criteria. Every word of it is right except that the only engineer who has touched the payments service is the one on support rotation. The model had the availability data and used it as a headcount number, not as a skills map, because a list of names and days off says nothing about who knows what. The plan passes review because it looks like a plan, and the sprint fails in week two.

Guard against that with one question asked out loud after the draft, never before it: for each item, who specifically would pick this up, and are they available? That question is boring, it takes four minutes, and it catches the entire class of failure. It is also the moment a drafted plan becomes a committed one, which is exactly where a human has to be standing.

Is this just faster planning theatre?

It can be. If your sprints already fail because the team commits to work it cannot finish, a model that generates a more articulate version of an over ambitious plan makes the problem worse and more defensible. A well formatted plan is harder to argue with than a scrappy one, and that is a real risk, not a rhetorical one.

The honest test is whether the drafted plan ever gets cut in the room. If the first draft survives planning untouched, week after week, the team has stopped deciding and started approving. Beyond Agile makes the same argument about ceremonies generally: keep the rituals that produce a real feedback loop, kill the ones that only produce a document. A generated sprint plan is a document until somebody removes something from it.

Which call stays with the humans, every time?

What to cut. A model will tell you what fits arithmetically; it cannot tell you what the team can absorb alongside two incidents, a hiring loop and a stakeholder who changes their mind on Thursdays. It also cannot weigh the thing teams actually trade off in planning, which is morale against throughput, and it has no view on whether shipping a mediocre version of a feature this sprint costs you the trust you need next quarter.

Keep three decisions off the model permanently: what gets cut when the plan does not fit, what the sprint goal is, and whether an item is ready enough to start. The first two are commitments. The third is a judgement about your own Definition of Done, which is local to your team and written nowhere the model can read.

Turn a drafted plan into a cadence that holds

A drafted plan is worth having every sprint, which means the skill that matters is not prompting but knowing what a good plan looks like before you read one. Project Management for Product runs one week on exactly that: slicing work without false certainty, tracking dependencies across teams, and running planning, reviews and retros as a cadence rather than a calendar habit. It sits inside the Product Delivery Specialist Track alongside the delivery skills that make a plan survive contact with the quarter.

See the Project Management for Product bootcamp

For the layer under this one, how AI helps with estimation covers breaking scope down before it reaches planning, and AI for capacity planning covers the quarter above it. The full delivery path lives in the Product Delivery Specialist Track, and if your planning problem is really a backlog problem, start with AI for backlog refinement instead.