Build a retrospective agenda from sprint events
Turn a list of what happened during a sprint into a retrospective agenda: themes to probe, blame-free questions and a concrete decision format.
Last updated
Fill in the blanks
Assembled in your browser — nothing you type is stored or sent anywhere.
Your prompt
Model-agnostic — works in Claude, ChatGPT, Gemini or any AI chat.
Why this prompt works
- →Grouping events into themes instead of listing a topic per event prevents a retro agenda from turning into a blow-by-blow recap that eats the whole meeting before any discussion happens.
- →Requiring each question to probe process or circumstances rather than a person's choices is the specific mechanism that keeps a retro blame-free, which is harder to enforce with a vague instruction like "be constructive."
- →Ending on a fixed number of owned action items, instead of an open-ended "things to consider," is what makes the retro produce an actual commitment the team can be held to next sprint.
Part by part
- 2-4 themes worth discussing (not a topic per event)
- Forces synthesis. A retrospective that walks an event list is a status review, and it runs out of time before reaching anything structural.
- invites explanation rather than assigning blame
- The framing that determines whether people speak. A question implying fault produces defensiveness and stops the discussion the meeting exists for.
- ask about the process or circumstances
- Makes the previous instruction concrete. Asking what made the deploy risky gets a different and more useful answer than asking who deployed it.
- a fixed number of concrete changes the team will commit to trying next sprint, each with an owner
- The output. A retrospective without owned actions produces the same discussion next month, which is why teams stop attending them.
Common mistakes
Write a retrospective agenda.Produces the standard went-well, went-badly, action-items template, which the team already knows. The work is in turning this sprint's events into themes, and that needs the events.
What went wrong this sprint?Frames the meeting as fault-finding before it starts. The most valuable retrospectives examine things that went fine but nearly did not, and that framing excludes them.
List action items from these events.Skips the discussion and produces actions nobody agreed to. Ownership comes from the conversation; a list handed down is a list that does not get done.
Questions
Why group events into themes?
Because individual events are usually symptoms. Three separate delays that all trace to one review bottleneck are one discussion, and walking them separately produces three shallow fixes instead.
How many actions should come out?
Two or three. A retrospective producing eight actions produces none, because nothing gets attention — and the failure is then attributed to the process rather than to the number.
Why do questions about people fail?
Because they invite justification rather than explanation. "What made this hard to catch?" and "why did you miss it?" seek the same information, and only one of them gets an honest answer.
What if the sprint genuinely went fine?
Then examine what nearly went wrong, or what the team is quietly working around. A retrospective with nothing to discuss usually means the interesting problems have become normal.