Skip to content

Retrospective Template

Retrospectives are how teams learn. A good retro surfaces what's actually happening, generates actionable improvements, and creates shared ownership of how the team works. A bad retro is a venting session that produces a list of complaints no one acts on.

This template provides structure that makes retros productive without making them mechanical.

What problem this solves

Teams accumulate friction: processes that don't work, communication gaps, unclear ownership, recurring frustrations. Without a regular mechanism to surface and address these issues, they compound. Retrospectives create a protected space to inspect how the team is working and make deliberate adjustments.

When to use this

Use retrospectives:

  • At the end of each sprint or iteration (every 1–2 weeks).
  • After significant milestones or releases.
  • When the team feels stuck or frustrated.
  • After incidents or project failures (separate from technical postmortems).

Don't use retrospectives for:

  • Technical incident analysis (use a postmortem).
  • Project planning (use planning sessions).
  • Individual performance feedback (use 1:1s).

Roles and ownership

Role Responsibility
Facilitator Runs the meeting. Keeps time. Ensures everyone participates. Stays neutral.
Team members Come prepared. Participate honestly. Commit to actions.
Manager (if present) Listens more than speaks. Doesn't dominate. Creates safety for candor.

Rotate the facilitator role. When the same person always facilitates, the retro becomes their meeting instead of the team's.

How to run the retrospective

Before the meeting

  • Send a reminder with the retro format and any data to review (metrics, incidents, feedback).
  • For remote teams: open a shared board (Miro, FigJam, or similar) where people can add items asynchronously before the meeting.

During the meeting (60 minutes)

1. Set the stage (5 min)

  • State the purpose: "We're here to improve how we work together."
  • Remind the team of the Prime Directive: "Everyone did the best they could given what they knew and the circumstances."
  • Review any relevant data or context.

2. Gather data (15 min)

Have each person add items to three categories:

  • What went well: Successes, wins, things to continue.
  • What didn't go well: Frustrations, blockers, things to stop or change.
  • Questions or observations: Things that feel unclear or worth discussing.

For remote teams, use silent writing time followed by sharing. This ensures quieter voices get heard.

3. Group and prioritize (10 min)

  • Cluster similar items.
  • Dot-vote to identify the top 2–3 topics to discuss. You won't have time for everything—prioritize ruthlessly.

4. Discuss and decide (25 min)

For each prioritized topic:

  • Understand the issue: What's actually happening? Why does it matter?
  • Generate options: What could we do differently?
  • Decide on action: What will we actually do? Who owns it?

Every action item must have an owner and a clear definition of done.

5. Close (5 min)

  • Recap the actions.
  • Ask: "How was this retro? Anything to improve next time?"
  • Thank the team.

After the meeting

  • Post the actions in a visible place (team channel, board, or wiki).
  • Review action status at the start of the next retro—this creates accountability.

Signals that retros are working

  • Actions from previous retros are completed.
  • The same issues don't recur repeatedly.
  • Team members participate openly.
  • Improvements are visible in how the team works.
  • The team looks forward to retros (or at least doesn't dread them).

Failure modes and mitigations

Failure mode What it looks like Mitigation
Venting without action Lots of complaints, no changes Enforce that every discussion produces an owner and an action
Same issues every retro "We talked about this last month" Track actions; investigate why they're not getting resolved
Dominant voices One or two people talk; others stay silent Use silent writing; round-robin sharing; explicitly invite quieter members
Unsafe to be honest Only safe topics surface; hard truths stay hidden Manager models vulnerability; address trust issues directly
Retros get skipped "We're too busy" Protect the time; make retros shorter if needed, but don't skip them

The template

Retrospective board structure

# Retrospective: [Team Name]

**Date:** [Date]
**Facilitator:** [Name]
**Attendees:** [Names]

---

## What went well ✅

- [Item]
- [Item]

## What didn't go well ❌

- [Item]
- [Item]

## Questions / Observations ❓

- [Item]
- [Item]

---

## Discussion notes

### Topic 1: [Topic]

**Summary:** [What we discussed]

**Decision:** [What we decided]

**Action:** [Action item] — Owner: [Name] — Due: [Date]

### Topic 2: [Topic]

[...]

---

## Actions from this retro

| Action     | Owner  | Due    | Status |
| ---------- | ------ | ------ | ------ |
| [Action 1] | [Name] | [Date] | ☐      |
| [Action 2] | [Name] | [Date] | ☐      |

---

## Review of previous actions

| Action                   | Owner  | Status                                    |
| ------------------------ | ------ | ----------------------------------------- |
| [Action from last retro] | [Name] | ✅ Done / 🔄 In progress / ❌ Not started |

Alternative formats

If the standard format gets stale, try:

  • Start / Stop / Continue: What should we start doing? Stop doing? Keep doing?
  • 4Ls: Liked, Learned, Lacked, Longed for.
  • Sailboat: Wind (what's pushing us forward), Anchor (what's holding us back), Rocks (risks ahead), Island (our goal).

Rotate formats occasionally to keep the retro fresh.