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.

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.

Scenario: Sprint 42 team retrospective

This is the INPUT brief for an output-quality eval. The skill arm and the control arm each receive everything below (and nothing else about how to do the work) and produce a retrospective artifact for it. Judges never see this header.

Context

Team: a 7-person product squad (PM, designer, 4 engineers, QA) on a payments product. Period: Sprint 42, a two-week sprint that ended Friday. The sprint included a production incident. Attendees at the retro: all 7. Two engineers (Priya, Marco) tend to dominate; the QA (Sam) and one backend engineer (Lee) were quiet.

Raw input gathered before/at the retro

What people said went well:

• The new payment-method UI shipped and early feedback is positive (designer, PM).
• Pairing on the refund bug "unblocked us in an hour instead of a day" (Priya).
• QA caught a currency-rounding bug before release (PM, crediting Sam).

What people said was rough:

• A production incident on Wednesday: a config change took checkout down for ~25 minutes. No clear

owner during the incident; people weren't sure who was on call.

• "We pulled in two extra tickets mid-sprint and nothing got cut, so everything slipped" (Marco).
• Designer felt design review happened too late, after engineers had already built.
• Lee mentioned (quietly) that the staging environment was broken for two days and slowed testing.
• Estimates were "wildly off" on the integration ticket.

Previous retro's action items (Sprint 41): 1. "Set up a clear on-call rotation" - owner: Priya - status: NOT done. 2. "Add a design-review checkpoint to the start of each ticket" - owner: designer - status: partially done (tried once). 3. "Document the staging reset procedure" - owner: Lee - status: done.

What the team wants from the artifact: a documented retro a missing teammate could read, with prioritized improvements and owned, dated action items, and a review of the prior actions. Facilitator is the PM.

iterate-retrospective - Version History

2.1.0 (2026-06-10)

Quality-convergence minor (F-12 Batch 3): added a "When NOT to Use" section with boundary pointers to neighboring skills, and the Output Format now enumerates the template sections a complete artifact fills. No template or example changes.

2.0.1 (2026-06-10)

Description-only patch (F-12 Batch 0, from the 2026-06-09 repo audit): the trigger-surface description was rewritten to disambiguate collision pairs with an explicit boundary pointer to the sibling skill. No body, template, or behavior changes.

2.0.0 (2026-01-26)

Baseline row for the prior published version; see git history for its changes.

Retrospective: Sprint 14 - Payment Feature Launch

Overview

Period Covered: January 1-14, 2026 (Sprint 14) Date Held: January 14, 2026 Facilitator: Maya Chen, Scrum Master Duration: 60 minutes Format Used: Start/Stop/Continue

Attendees

• Alex Rivera, Engineering Lead
• Jordan Kim, Senior Engineer
• Sam Patel, Engineer
• Chris Wong, Engineer
• Taylor Brooks, Product Manager
• Maya Chen, Scrum Master

Context

Sprint 14 included the launch of our new payment processing feature, which was a company priority. The team successfully shipped on time despite a mid-sprint requirements change. We also onboarded a new team member (Chris) during this sprint. There was one production incident (P2) related to payment timeout handling that was resolved within 4 hours.

---

Previous Retrospective Review

Action Items from Last Retro

---

What Went Well

Team Highlights

• Shipped payment feature on time despite mid-sprint requirements change
• Zero critical bugs found in production after launch
• Team rallied together during the P2 incident.great cross-functional response
• New PR template caught several issues before merge

Process Wins

• Design sync meeting eliminated 3+ days of async back-and-forth
• Pair programming on complex payment logic reduced bugs
• Daily standups stayed focused and under 15 minutes

Individual Shoutouts

• Jordan: Stepped up to mentor Chris during onboarding while maintaining velocity
• Sam: On-call response to P2 was exemplary.clear communication, fast resolution
• Taylor: Requirements change was communicated with context, not just "do this"

---

What to Improve

Challenges Faced

• Mid-sprint requirements change caused context switching and rework
• Test environment was unstable for 2 days, blocking integration testing
• P2 incident revealed gap in timeout handling documentation
• Chris felt unsure where to find information as new team member

Process Pain Points

• Requirements changes mid-sprint.how do we protect sprint scope better?
• Flaky tests are getting worse.5 tests failed intermittently this sprint
• On-call runbook is still incomplete.we were lucky Sam knew what to do
• Onboarding documentation is outdated

Themes Identified

---

Discussion Notes

Test Reliability (Highest Priority)

What was discussed: The team is frustrated with flaky tests. We identified 5 tests that have failed intermittently in the past month. Each failure wastes ~30 minutes investigating and re-running. The test environment instability was a separate issue (AWS configuration) but compounded the frustration.

Root cause identified:

• 3 tests have race conditions in async code
• 2 tests depend on external services without proper mocking
• Test env issue was due to expired credentials (now fixed)

Proposed solution: Dedicate 1 story point per sprint to fixing flaky tests until backlog is clear. Start with the 3 race condition tests since those are highest impact.

---

Documentation Gaps

What was discussed: Chris mentioned that onboarding was harder than it needed to be.docs pointed to systems that no longer exist or had wrong information. The P2 incident also showed that our runbooks are incomplete. If Sam hadn't been on call, resolution would have taken longer.

Root cause identified:

• No owner for documentation maintenance
• Docs aren't part of our definition of done
• Runbooks were started but never finished

Proposed solution: 1. Sam will finish the on-call runbook this sprint (carryover) 2. Chris will update onboarding docs while experience is fresh 3. Consider adding "docs updated" to PR checklist for relevant changes

---

Scope Protection

What was discussed: The mid-sprint requirements change (adding Apple Pay support) was justified from a business perspective, but the team felt it was handled poorly. The change added 3 story points mid-sprint without removing anything.

Root cause identified:

• No clear escalation path for mid-sprint changes
• PM felt pressure to say yes without consulting team on impact
• We don't have a "scope change" process

Proposed solution: Create a lightweight process: any mid-sprint addition requires (1) PM-Eng discussion of impact, (2) something of equal size removed or explicit scope increase acknowledgment, (3) documented reason. Taylor and Alex will draft this.

---

Action Items

Action Item Details

Action 1: Fix race condition tests

• What: Fix the 3 tests identified as having race conditions (test_async_payment, test_webhook_handler, test_batch_process)
• Why: Test reliability theme.reducing CI failures and investigation time
• Success criteria: Tests pass 50 consecutive times in CI

Action 2: Complete on-call runbook

• What: Finish documenting P1/P2 response procedures, escalation paths, and common issues
• Why: Documentation gaps theme.P2 incident showed risk
• Success criteria: Runbook reviewed by Alex and used in next on-call rotation

Action 3: Update onboarding documentation

• What: Review and update new developer onboarding guide, remove references to deprecated systems
• Why: Chris's experience showed docs are outdated; best to fix while fresh
• Success criteria: New hire (future) can set up environment using only docs

Action 4: Draft scope change process

• What: Create 1-page process for handling mid-sprint scope changes
• Why: Scope protection theme.prevent future frustration from unplanned changes
• Success criteria: Team agrees to trial process in Sprint 15

---

Parking Lot

• Tech debt backlog review: We have 47 items in tech debt backlog. Should schedule a grooming session, but not urgent. Defer to Sprint 16 planning.
• Pair programming formalization: Team liked pairing on payment feature but want to discuss how to make it more regular. Add to Sprint 16 retro agenda.

---

Metrics and Trends

Team Health Indicators

Recurring Themes

• Test reliability has appeared in 3 of last 5 retros. This sprint we're committing to fixing the top issues.
• Documentation has appeared in 2 of last 5 retros. We now have 2 specific actions to address it.

---

Facilitator Notes

• Start/Stop/Continue worked well for this team.consider alternating with 4Ls next time for variety
• Should timebox discussion sections more strictly.we ran 5 min over
• Anonymous input submission before meeting helped quieter team members contribute equally

---

Next Retrospective

Scheduled: January 28, 2026 Focus areas: Check in on scope change process trial, test reliability progress

---

Retrospective documented by Maya Chen on January 14, 2026.

Retrospective: [Sprint/Project Name]

Overview

Period Covered: [Date range or project name] Date Held: [When retrospective occurred] Facilitator: [Who led the session] Duration: [How long] Format Used: [Start/Stop/Continue, 4Ls, Mad/Sad/Glad, etc.]

Attendees

• [Name, Role]
• [Name, Role]
• [Name, Role]
• [Name, Role]

Context

<!-- Notable events, releases, or circumstances that affected this period -->

[Brief summary of what happened during this period]

---

Previous Retrospective Review

Action Items from Last Retro

---

What Went Well

<!-- Celebrate successes and reinforce positive behaviors -->

Team Highlights

• [Success 1]
• [Success 2]
• [Success 3]

Process Wins

• [What worked well in how we work]
• [What worked well in how we work]

Individual Shoutouts

• [Recognition for specific contributions]

---

What to Improve

<!-- Identify challenges and opportunities for growth -->

Challenges Faced

• [Challenge 1]
• [Challenge 2]
• [Challenge 3]

Process Pain Points

• [What didn't work well in how we work]
• [What didn't work well in how we work]

Themes Identified

<!-- Group similar items into themes -->

---

Discussion Notes

[Topic 1]

What was discussed: [Summary of discussion]

Root cause identified: [If applicable]

Proposed solution: [What the team agreed to try]

---

[Topic 2]

What was discussed: [Summary of discussion]

Root cause identified: [If applicable]

Proposed solution: [What the team agreed to try]

---

Action Items

<!-- Every action needs an owner and due date -->

Action Item Details

Action 1: [Title]

• What: [Detailed description of what needs to happen]
• Why: [Which improvement this addresses]
• Success criteria: [How we know it's done]

Action 2: [Title]

• What: [Detailed description of what needs to happen]
• Why: [Which improvement this addresses]
• Success criteria: [How we know it's done]

---

Parking Lot

<!-- Items raised but deferred for future discussion -->

• [Topic 1]: [Why deferred]
• [Topic 2]: [Why deferred]

---

Metrics and Trends

<!-- Optional: track retro patterns over time -->

Team Health Indicators

Recurring Themes

<!-- Note if issues keep coming up -->

• [Theme that has appeared multiple times]

---

Facilitator Notes

<!-- Private notes for improving future retros -->

• [What worked in facilitation]
• [What to try differently next time]

---

Next Retrospective

Scheduled: [Date] Focus areas: [Any specific topics to address]

---

Retrospective documented by [Name] on [Date].