How to Prompt AI to Write a Sprint Retrospective

How to prompt AI to write a sprint retrospective starts with feeding it the raw material a retro actually runs on, completed and incomplete tickets, what slipped and why, any incident or blocker notes, rather than asking it to invent reflections from nothing. A retrospective an AI writes from a vague "how did the sprint go" prompt reads like generic filler. One built from the sprint's actual ticket history reads like it was written by someone who was paying attention, because in a sense it was. It's one more entry in the same raw-material-in approach that runs through the rest of this prompting series.

What to feed it

• The list of tickets planned versus tickets actually completed, with anything that slipped flagged as such.

• Any blocker, incident, or scope-change notes from the sprint, even rough ones from a standup channel.

• The previous retro's action items, so the new one can report on whether they actually happened.

• Raw, unfiltered feedback if you have it, a few lines from each team member rather than a single blended summary, which lets the AI preserve genuine disagreement instead of smoothing it into consensus that didn't exist.

The previous action items are the input most retros skip reusing, and it's the one that turns a retro from a ritual into an actual feedback loop. An AI prompted to open with "last sprint we said we'd do X, here's what happened" produces something a team reads differently than a retro that starts from zero every two weeks.

A structure that holds up

Four sections, in this order, works better than the classic three-column what-went-well/what-didn't/action-items board once AI is doing the drafting, because it forces a connection between the retrospective and the last one instead of two disconnected snapshots:

1. Follow-up on last sprint's action items: done, partially done, or dropped, and why.

2. What went well, specific enough to repeat, not "good communication" but "the daily async update in the channel caught the API contract mismatch two days before it would have blocked QA."

3. What didn't, framed as a pattern or a system issue where possible rather than pointing at a person. "Three of five slipped tickets were blocked on the same external API's rate limit" is more useful and safer to write than a list of who missed their estimate.

4. This sprint's action items, each with an owner and something specific enough to check off, not "communicate better" but "add the external API rate limit to the sprint planning checklist."

A prompt that produces this

Draft a sprint retrospective from this raw material: [paste ticket list, blocker notes, and last retro's action items]. Structure it as: follow-up on last sprint's action items, what went well (specific examples only), what didn't (framed as patterns, not individuals), and this sprint's action items with an owner and a concrete definition of done for each. Keep the tone direct and specific, no generic team-building language.

The "framed as patterns, not individuals" instruction matters more than it looks. Left unprompted, a model summarizing raw feedback will sometimes reproduce a complaint about a specific person's pace or communication style verbatim, which is the fastest way to turn a retro document into something nobody wants to be honest in next time. Explicitly asking for the systemic framing is a real behavior change, not a stylistic nicety.

Where this differs from an incident update

A retro looks backward across a whole sprint's pattern of work; an incident update is about one specific event as it unfolds or just resolved. They share the instinct of pulling from raw notes rather than a blank page, but the structure and audience differ enough that they're worth treating separately: see how to prompt AI to write an incident update for the narrower, single-event version of this same raw-material-in approach.

Keep a human editing pass before it goes out

Treat the AI draft as the first cut, not the final version. The person running the retro should still read it before the meeting and adjust anything that misreads a nuance, softens a pattern that actually needs to be said plainly, or attributes something to the wrong root cause. This is the same discipline as any AI-assisted writing meant to represent a group rather than one person's voice: draft fast, then have a human who was actually in the sprint sign off on whether it's accurate, not just whether it reads well. The same raw-material approach extends to test coverage instead of team process: see how to prompt AI to write a test plan for that version.

Frequently asked questions

Should the AI draft be shown to the team before or during the retro meeting?

Before, ideally a day ahead, so people read it and come to the meeting ready to discuss or correct it rather than reading it live and reacting in real time. A retro that starts with everyone silently reading a document wastes the most valuable part of the meeting, the discussion.

What if the raw material is thin, a quiet sprint with nothing dramatic?

Say so in the prompt rather than letting the AI pad a quiet sprint into something that sounds more eventful than it was. "This was a quiet sprint, most tickets went as planned" is a legitimate and honest retro, and a good prompt should produce exactly that rather than manufacturing drama to fill a template.

Can this work for a solo project without a team retro meeting?

Yes, and it's arguably more valuable solo, since there's no meeting discussion to catch what a written retro misses. The same four-section structure works as a personal log: what you said you'd fix last time, what actually went well, what patterns are slowing you down, and what you'll specifically change next.