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:

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.

Project Memory Contract

Active only when .claude/pm-skills.local.md exists. With no file, ignore this section entirely and behave exactly as described above.

• Reads: the recent artifacts[] entries, so the retrospective can look at what the cycle actually produced instead of relying on recall.
• Writes: the lessons as an interpretation artifact.
• Posture: propose the entry and wait for confirmation before writing, unless memory_auto_append: true is set, in which case append and echo what was written.

A retrospective surfaces raw observations, patterns, and commitments at once. Record the durable half, the lessons, under a single tag; a downstream reader needs to know how firmly to weight the entry, and a mixed tag tells it nothing.

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.