🔄 Retrospective Facilitation

Synthesize Retro Feedback Into 3 Action Items

Turns messy retro notes into exactly 3 prioritized, owned action items. Built for PMs running async retros or compiling feedback from multiple sprints.

This prompt synthesizes retro feedback into exactly 3 prioritized action items using an impact-feasibility matrix. Each action item has an owner, a first step, a deadline, and a success criterion.

When to use this prompt

Use this after a retrospective when you have a pile of notes and stickies and need to compress them into actionable next steps. You will need the raw retro feedback and the list of attendees. The prompt enforces exactly 3 action items because teams cannot execute on more than that in a single sprint. It also assigns owners and defines success criteria, which are the two things retros consistently miss. Do not use it if your retro already produced clear action items; the synthesis is valuable only when the retro generated more ideas than decisions.

The Prompt

Role: Product Manager Variables: {{retro_feedback}}, {{attendees}}, {{sprint_name}}, {{capacity}}

You are a product manager synthesizing retrospective feedback into exactly 3 prioritized action items. Use an impact-feasibility matrix and assign clear ownership.

Retro feedback:
{{retro_feedback}}

Attendees: {{attendees}}
Sprint name: {{sprint_name}}
Team capacity for next sprint: {{capacity}}

Produce the synthesis in this structure:

1. THEMES — Cluster the raw feedback into 4-6 themes. For each theme, list the supporting items and the number of participants who mentioned it.

2. IMPACT-FEASIBILITY MATRIX — Rank each theme by IMPACT (would fixing it materially improve team outcomes?) and FEASIBILITY (can it be addressed in the next sprint?). Use the matrix to identify the quadrant each theme sits in: HIGH IMPACT/HIGH FEASIBILITY, HIGH IMPACT/LOW FEASIBILITY, LOW IMPACT/HIGH FEASIBILITY, LOW IMPACT/LOW FEASIBILITY.

3. TOP 3 ACTION ITEMS — From the HIGH IMPACT/HIGH FEASIBILITY quadrant, pick 3 action items. For each:
- Title
- Specific first step
- Owner (named individual from attendees)
- Deadline (within next sprint)
- Success criterion (how we will know it worked)

4. LONG-TERM PARKING LOT — Items from the HIGH IMPACT/LOW FEASIBILITY quadrant that should be tracked but cannot be addressed now. List them with the reason they are not feasible this sprint.

5. DROPPED — Items from the LOW IMPACT quadrants that will not be acted on. List them with a 1-line reason so the team knows they were heard and explicitly dropped.

Rules:
- Exactly 3 action items. No more, no fewer.
- Every action item must have a single owner; co-ownership is no ownership.
- Success criteria must be observable, not aspirational.
- If the HIGH IMPACT/HIGH FEASIBILITY quadrant has fewer than 3 themes, flag this honestly. Pad from LOW IMPACT/HIGH FEASIBILITY only if necessary.

Example Output

THEMES
1. Standup runs over (mentioned by 5 of 7) — supporting items: "too long", "too detailed", "people talking past each other"
2. PR reviews bottlenecked on tech lead (4 of 7) — "waiting 2 days", "tech lead is burnt out", "I reviewed my own PR"
3. Definition of done is unclear (3 of 7) — "shipped without analytics", "no docs", "what is 'done' here?"
4. On-call rotation feels unfair (2 of 7) — "same 3 people every weekend"
5. We don't celebrate shipping (3 of 7) — "team morale"

IMPACT-FEASIBILITY MATRIX
- Standup over-run: HIGH impact, HIGH feasibility (process tweak)
- PR review bottleneck: HIGH impact, HIGH feasibility (add second reviewer)
- Definition of done: HIGH impact, HIGH feasibility (update checklist)
- On-call rotation: HIGH impact, LOW feasibility (needs HR involvement)
- Celebration: LOW impact, HIGH feasibility

TOP 3 ACTION ITEMS
1. Cap standups at 2 minutes per person, starting Monday. First step: facilitator posts new rule in team channel. Owner: Priya. Deadline: Monday Sprint 15. Success: average standup length under 15 minutes for 5 consecutive days.
2. Add Mika and Tomas as approved reviewers for PRs. First step: update GitHub CODEOWNERS file. Owner: Tech Lead (Dan). Deadline: Tuesday Sprint 15. Success: median PR review time drops from 48 to 12 hours within 1 sprint.
3. Update definition of done to include instrumentation and docs. First step: draft new DoD in team wiki. Owner: PM (Marco). Deadline: Wednesday Sprint 15. Success: next sprint's closed tickets all include instrumentation evidence.

LONG-TERM PARKING LOT
- On-call rotation fairness — needs HR and people ops involvement; will address in next quarter.

DROPPED
- Celebration ritual — low impact, can be addressed informally.

Recommended Tools

Linear and ClickUp both let you create action items as tasks directly from the synthesis, which ensures they enter the next sprint rather than living only in retro notes. Notion projects is better when the team retains retro history and wants to see action items alongside themes. Use Linear or ClickUp when you want execution tracking; use Notion when the context around each action item matters for future reference.

Linear74/100 Notion Projects76/100 ClickUp94/100

Frequently Asked Questions

When should I use this prompt?

Use it at the end of a retro when the team has generated more ideas than time to discuss them, or when you are running an async retro and need to consolidate feedback from multiple contributors. It is also useful for compiling action items from multiple sprints' worth of retros when the team is preparing for a quarterly review. Do not use it if the retro already produced 1-3 clear action items; in that case, just use those and skip the synthesis step. The prompt is for situations where the team generated too much input to act on directly.

Why exactly 3 action items?

Teams consistently fail to execute on more than 3 action items per sprint because attention is the scarce resource. Committing to 5 or 6 action items produces a pattern where only 1-2 get done and the rest accumulate as invisible failures that erode retro credibility. Limiting to 3 forces the team to choose what matters most, which is a valuable exercise in itself. If 3 feels too few, that is usually a signal that the team has been hoarding unfinished improvements across many retros; the fix is to do the 3 well, not to commit to more and hope.