Iterate Retrospective

<!-- PM-Skills | https://github.com/product-on-purpose/pm-skills | Apache 2.0 -->

Retrospective

A retrospective is a structured reflection that helps teams learn from their experiences and continuously improve. By regularly examining what went well, what didn't, and what to change, teams build a culture of learning and adaptation. The value isn't just in the discussion.it's in the documented actions and follow-through.

When to Use

• At the end of every sprint (for agile teams)
• After completing a significant project or milestone
• Following a major incident or outage
• When team dynamics feel off and need addressing
• At regular intervals (monthly, quarterly) even without specific triggers
• When onboarding new team members to establish improvement culture

When NOT to Use

• You want one durable learning banked for the organization -> use iterate-lessons-log; the retro is the ceremony, the log entry outlives it
• You are scoring an OKR cycle at close -> use measure-okr-grader
• The reflection must end in a pivot-or-persevere call -> use iterate-pivot-decision
• You need a recap of a general (non-retro) meeting -> use foundation-meeting-recap

Instructions

When asked to facilitate or document a retrospective, follow these steps:

• Set the Context

Define what period or project this retrospective covers, who attended, and any significant events that occurred. This frames the discussion and helps future readers understand the context.

• Choose a Format

Select a retrospective format that fits the team's needs. Common options include:

• Start/Stop/Continue: Simple and direct
• 4Ls: Liked, Learned, Lacked, Longed for
• Mad/Sad/Glad: Emotion-focused
• Sailboat: Visual metaphor (wind=helps, anchor=holds back)

• Gather Input

Collect observations from all team members. Ensure everyone contributes.quiet voices often have important insights. Group similar items to identify themes.

• Discuss and Prioritize

Don't try to address everything. Focus the discussion on the most impactful items. Vote or discuss to identify the top 2-3 issues to address.

• Define Action Items

Convert insights into specific, assignable actions. Every action needs an owner and a due date. Avoid vague improvements like "communicate better."

• Review Previous Actions

Check the status of action items from the last retrospective. Celebrate completions and discuss blockers for incomplete items. This builds accountability.

• Document for Future Reference

Capture the key points so they're available for future team members and for tracking patterns over time.

Output Format

Use the template in references/TEMPLATE.md to structure the output. A complete retrospective fills every template section: Overview; Previous Retrospective Review; What Went Well; What to Improve; Discussion Notes; Action Items; Parking Lot; Metrics and Trends; Facilitator Notes; and Next Retrospective.

Quality Checklist

Before finalizing, verify:

• [ ] All attendees had opportunity to contribute
• [ ] Both positives and improvements are captured
• [ ] Action items have owners and due dates
• [ ] Previous retrospective actions are reviewed
• [ ] A reader who missed the retro can tell what was decided and who owns each action from this document alone

Examples

See references/EXAMPLE.md for a completed example.