Retro Runner

Facilitate structured retrospectives that produce concrete improvements — not just venting sessions. Works for sprints, launches, experiments, incidents, or any milestone worth reflecting on.

When to Use

• "Run a retro on..."
• "What went well / badly with..."
• "Post-mortem for..."
• "Let's reflect on the launch"
• After any milestone, sprint, or incident
• When the team feels stuck in repeat patterns

Process

1. Set the Scope

Ask (one at a time):

• What are we retro-ing? (sprint, launch, experiment, incident, quarter)
• Time window? (last 2 weeks, last month, since launch)
• Who was involved? (just you, your squad, cross-functional team)

2. Gather Signals

Prompt the user for input in four categories:

What worked — things to keep doing

• What felt smooth?
• What results exceeded expectations?
• What should we do more of?

What didn't work — things to stop or change

• Where did we feel friction?
• What took longer than expected?
• What would we do differently?

What surprised us — things we didn't predict

• Unexpected wins or failures
• Customer behavior we didn't anticipate
• Dependencies or blockers we missed

What we learned — durable insights

• New knowledge about our users, product, or process
• Patterns across multiple retros (reference memory/ for prior retros)

3. Identify Patterns

Cross-reference with prior retros if available:

• Read memory/decisions/ for related past decisions
• Check if the same issues recurred — flag repeat offenders
• Note if a previous action item would have prevented this issue

4. Extract Action Items

For each issue identified:

• Action — specific, verb-first improvement
• Owner — who will drive it
• Type — process change, tool fix, communication fix, skill gap
• Reversibility — is this easy to try and revert?
• Due — when should this be done

Prioritize ruthlessly: max 3 action items. More than 3 means nothing gets done.

5. Log the Decision

Write the retro output to memory/decisions/YYYY-MM-DD_retro-[topic].md so future retros can reference it.

Output

## Retro: [Topic]

**Date:** YYYY-MM-DD
**Scope:** [what was retro'd]
**Participants:** [who was involved]

### What Worked
- [item]

### What Didn't Work
- [item]

### Surprises
- [item]

### Patterns
- [recurring theme or first-time issue]

### Action Items (max 3)
| # | Action | Owner | Type | Due |
|---|--------|-------|------|-----|
| 1 | [specific action] | [name] | [type] | [date] |
| 2 | [specific action] | [name] | [type] | [date] |
| 3 | [specific action] | [name] | [type] | [date] |

### Key Takeaway
[One sentence: the most important thing we learned]

Principles

• Blameless — focus on systems, not people
• Pattern-aware — connect to prior retros
• Action-capped — max 3 items, or nothing sticks
• Forward-looking — retros exist to improve the future, not relitigate the past