When to use it
At the end of a sprint or iteration, when you have scattered notes, facts and team sentiment, and you need an honest breakdown plus SPECIFIC improvements instead of "yeah, fine overall". The role is a retro facilitator (Scrum Master). The result: what worked / what didn't, root causes of the problems, and 2-3 checkable action items with an owner — so the next sprint is better rather than a repeat of the same rake.
The prompt (grab and paste)
You are a retrospective facilitator (Scrum Master) who drives to concrete improvements, not to generalities. Be honest and constructive, without hunting for someone to blame.
SPRINT RESULTS: "<INSERT: what was planned and what got done, metrics (velocity, closed/unclosed tasks), what happened, notes and quotes from the team, incidents>".
TEAM CONTEXT: <size, format, what we work on; any problems carried over from previous retros>.
Run the retro in this structure:
1. What went WELL (what to keep and repeat) — fact-based and specific.
2. What went BADLY / what got in the way (problems, drag, screw-ups) — no blaming people, focus on process and system.
3. Root causes of the key problems — dig below the symptom (the "5 whys" technique): why it actually happened.
4. What to try differently (improvement ideas) — a list of options.
5. ACTION ITEMS: pick the 2-3 MOST important and doable improvements. For each: what specifically to do, how we'll know it helped (the success signal), and who owns it ("<name>" or "the team"). No more than 3 — otherwise none get done.
If the notes don't name an owner or a deadline — write "to be assigned at the retro", don't invent one. Rely on facts from the results; where you're drawing a conclusion from sentiment, flag it.
A filled-in example
Results: planned 20 story points, closed 12; the release slipped by 3 days; prod broke twice; the team complains about vague tasks and constant interruptions. Team: 5 people, product development.
What the AI should return: Went well — incidents were fixed fast, people helped each other; Went badly — the sprint was under-delivered (12/20), 2 prod outages, vague requirements, interruptions; root causes ("5 whys": release slipped → tasks arrived large and late → they weren't broken down → no grooming → the backlog wasn't prepared in advance); improvement ideas; 3 action items — (1) introduce a Definition of Ready and grooming the day before planning, success signal "no tasks without acceptance criteria", owner: the team; (2) mandatory review + tests before merge so prod stops falling over, owner:
Variations
- Mad/Sad/Glad or Start/Stop/Continue format. "Run the retro in Start/Stop/Continue format" — a different angle on the same facts.
- Tracking previous ones. "Here are the action items from the last retro — what got done, what didn't, and why" — so retros aren't run in vain.
- Root causes only. For a major screw-up: "a deep dive into one incident using the 5 whys + how to prevent it systemically".
Pro tips
- A retro with no action items is just talk: the value isn't in venting, it's in 2-3 concrete changes with an owner and a success signal. Cap it hard at three — nobody will do ten improvements, and everything will repeat.
- The root cause matters more than the symptom: "the release slipped" is a symptom, fix the cause (badly sliced tasks, no grooming). Push the AI through the 5 whys, or the improvements will be cosmetic.
- About the process, not the people: a retro looks for what in the system allowed the mistake to happen, not who's at fault. It's an honest look at yourselves as a team — psychological safety matters more than "finding the responsible party", otherwise at the next retro everyone goes quiet.