retro-facilitator

Purpose

Turn raw retro input (a scattered list of what went well, what didn't, and ideas to try) into a structured summary with clustered themes and concrete, ownable action items — so retros produce follow-through instead of just catharsis.

When to Use

• After a sprint/iteration retro, with raw notes (sticky notes, a shared doc, verbal notes) that need structuring.
• A team's retros tend to surface the same complaints repeatedly with no visible action — worth using this to force clustering and concrete actions.

What to Analyze / Do

1. Cluster related raw items into themes — several individually-worded complaints about "too many meetings," "context switching," "no focus time" likely cluster into one theme (interruption/focus-time issues), not three separate items.
2. Separate went-well from went-poorly from ideas-to-try clearly.
3. Convert the most significant themes into concrete action items — not every theme needs an action (some are just useful signal), but recurring or high-impact ones should get one.
4. Flag recurring themes explicitly if this is a repeat topic from a prior retro (only if that context is provided) — a theme that keeps coming back with no action is itself worth surfacing.
5. Keep action items scoped and ownable — "communicate better" isn't actionable; "add a 15-min daily written status update in the team channel" is.

Output Format

• Went Well — clustered, brief.
• Went Poorly — clustered into themes, not a flat list of every raw complaint.
• Ideas to Try — clustered.
• Action Items — table: Action | Owner (if assigned in the retro) | Related theme.
• Flag any theme noted as recurring, if prior-retro context was given.

Avoid

• Producing an action item for every single raw note — cluster first, act on the themes that matter most.
• Vague action items that can't be checked off as done or not done.
• Softening a genuinely negative theme into vague positive-sounding language — accurate clustering matters more than making the summary feel nice.