Summarize a Sprint Retro Into Themes and Owned Actions
Clusters messy retro notes into themes with root causes and a table of owned, dated actions.
Sprint retrospectives generate a wall of sticky notes and then, too often, nothing changes, because the raw notes never get turned into accountable action. This prompt does the synthesis a good facilitator does after the room clears. It clusters the scattered input into a few themes, separates symptoms from root causes (slow reviews are a symptom; an unbalanced reviewer load is the cause), and quantifies recurring pain where the data allows. Then it produces an action table where every item has one accountable owner-role and a check-in date, because actions without owners are wishes. The feature that makes retros actually improve a team is the carried-over flag: it surfaces any action from a prior retro that still hasn't happened, which is usually the real problem hiding in plain sight. Feed it your raw notes plus a couple of delivery facts like planned-versus-completed and any incidents. Keep the output short so the team reads it; a retro summary nobody opens is just more process debt.
Act as a delivery lead synthesizing a sprint retrospective for [TEAM]. Sprint goal was: [SPRINT GOAL]. Here are the raw retro notes, sticky-note style: [WHAT WENT WELL / WHAT DIDN'T / IDEAS]. Plus delivery facts: [PLANNED VS COMPLETED, ANY INCIDENTS]. Produce a summary that clusters the raw input into 3-5 themes, separates symptoms from root causes, and quantifies recurring pain where possible. Then create an action table: each action, the theme it addresses, a single accountable owner-role, and a check-in date. Highlight any action carried over from a prior retro that still isn't done. Close with one process experiment to try next sprint. Keep it under 350 words.
What you can expect back
Themes: 1) Review bottleneck, 2) Test instability, 3) Unclear requirements. Symptoms vs root causes: slow PRs (symptom) trace to two senior devs holding all reviews (root cause); pipeline blocks (symptom) come from three known-flaky e2e tests nobody owns (root cause); the Tuesday incident and two reworked tickets share a root cause of acceptance criteria written after work started. Quantified pain: ~13 of 34 points slipped, much of it waiting on review. Actions: (A) Rotate review duty across all five engineers, owner: tech lead, check-in next retro. (B) Quarantine the three flaky tests and file fix tickets, owner: QA-minded engineer, check-in mid-sprint. (C) PM drafts acceptance criteria before refinement, owner: product manager, check-in next planning. Carried over: 'rotate reviewers' appeared last retro and still isn't done, making it the top priority. Experiment next sprint: a 24-hour review SLA.
Illustrative example — your results will vary by tool and inputs.
Get sharper results
- 01Paste notes verbatim. The model clusters better from raw, messy input than from your pre-tidied summary.
- 02The carried-over flag is the highest-value line. An action that recurs across retros is your team's real constraint.
- 03Insist on one owner-role per action. Shared ownership is how good intentions quietly die.
- 04Keep one experiment per retro. Changing five things at once means you'll never know which one helped.
Adapt it for your case
Paste several retros' notes and ask for recurring themes that persist sprint over sprint.
Add: 'Keep all language blameless and focused on systems and process, never individuals.'
Ask for a three-bullet version for an engineering manager who only needs themes and blockers.
Common questions
Can this replace running an actual retro?
No. The conversation and team buy-in happen live; this prompt synthesizes the output afterward into themes and owned actions so the discussion turns into change.
Why separate symptoms from root causes?
Because teams usually act on symptoms ('reviews are slow') and the pain returns. Naming the root cause ('reviewer load is concentrated') points the action at something that actually fixes it.
What if the same action keeps showing up?
That's the most important signal in the summary. A repeatedly unfinished action is your team's true bottleneck and should jump to the top of the priority list.
You may also need
Board Update Memo With Metrics, Asks, and Honest Lowlights
Produces a candid, scannable board update with a metrics table, honest lowlights, and specific asks.
Executive Summary of a Long Document for Time-Poor Leaders
Condenses a long document into a layered executive brief tailored to one reader's priorities.
Draft OKRs That Cascade From Company Goal to Team
Drafts outcome-based OKRs that ladder up to the company goal and weeds out tasks masquerading as key results.
Summarize Meeting Notes Into Action Items
Turn messy meeting notes into a clean summary with decisions, owners, and follow-ups.