---
name: iterate-retrospective
description: Facilitates and documents a team retrospective capturing what went well, what to improve, and action items. Use at the end of a sprint, project, or milestone to reflect and improve team practices. To bank individual learnings into organizational memory afterward, use iterate-lessons-log.
license: Apache-2.0
metadata:
phase: iterate
version: "2.1.0"
updated: 2026-06-10
category: reflection
frameworks: [triple-diamond, lean-startup, design-thinking]
author: product-on-purpose
---
<!-- 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:
1. **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.
2. **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)
3. **Gather Input**
Collect observations from all team members. Ensure everyone contributes.quiet voices often have important insights. Group similar items to identify themes.
4. **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.
5. **Define Action Items**
Convert insights into specific, assignable actions. Every action needs an owner and a due date. Avoid vague improvements like "communicate better."
6. **Review Previous Actions**
Check the status of action items from the last retrospective. Celebrate completions and discuss blockers for incomplete items. This builds accountability.
7. **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.