¶

Quick facts

Phase: Iterate | Version: 2.0.0 | Category: reflection | License: Apache-2.0

Try it: /retrospective "Your context here"

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

How to Use¶

Use the /retrospective slash command:

/retrospective "Your context here"

Or reference the skill file directly: skills/iterate-retrospective/SKILL.md

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 Template¶

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¶

[Brief summary of what happened during this period]

Previous Retrospective Review¶

Action Items from Last Retro¶

Action	Owner	Status	Notes
[Action 1]	[Name]	Complete/In Progress/Not Started	[Update]
[Action 2]	[Name]	Complete/In Progress/Not Started	[Update]
[Action 3]	[Name]	Complete/In Progress/Not Started	[Update]

What Went Well¶

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¶

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¶

Theme	Items	Votes
[Theme 1]	[Related items]	[Vote count]
[Theme 2]	[Related items]	[Vote count]
[Theme 3]	[Related items]	[Vote count]

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¶

Priority	Action	Owner	Due Date	Status
1	[Specific action]	[Name]	[Date]	Not Started
2	[Specific action]	[Name]	[Date]	Not Started
3	[Specific action]	[Name]	[Date]	Not Started

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¶

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

Metrics and Trends¶

Team Health Indicators¶

Indicator	This Retro	Last Retro	Trend
Team morale (1-5)	[Score]	[Score]	↑/↓/→
Process satisfaction (1-5)	[Score]	[Score]	↑/↓/→
Collaboration (1-5)	[Score]	[Score]	↑/↓/→

Recurring Themes¶

[Theme that has appeared multiple times]

Facilitator Notes¶

[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].

Example Output¶

Retrospective: Sprint 14 — Payment Feature Launch

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¶

Action	Owner	Status	Notes
Create PR template with checklist	Alex	Complete	Now in use, team finds it helpful
Add Slack integration to CI pipeline	Jordan	Complete	Notifications working
Schedule design sync for Sprint 14	Taylor	Complete	Held on Jan 3, reduced back-and-forth
Document on-call runbook	Sam	In Progress	70% done, will finish this sprint

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¶

Theme	Items	Votes
Test reliability	Flaky tests, unstable test env	5
Documentation gaps	Runbooks incomplete, onboarding docs outdated	4
Scope protection	Mid-sprint changes, context switching	3

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¶

Priority	Action	Owner	Due Date	Status
1	Fix 3 race condition tests identified in CI	Jordan	Jan 21	Not Started
2	Complete on-call runbook (carryover)	Sam	Jan 21	In Progress
3	Update onboarding documentation	Chris	Jan 28	Not Started
4	Draft scope change process	Taylor + Alex	Jan 17	Not Started

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¶

Indicator	This Retro	Last Retro	Trend
Team morale (1-5)	4.0	3.5	↑
Process satisfaction (1-5)	3.5	3.5	→
Collaboration (1-5)	4.5	4.0	↑

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.

Real-World Examples¶

See this skill applied to three different product contexts:

Storevine (B2B): Storevine B2B ecommerce platform — Campaigns v1.0 build sprint retrospective

Prompt:

/retrospective

Sprint: Campaigns v1.0 build sprint + GA week
Period: February 3 – May 5, 2026 [fictional]
Date held: May 7, 2026
Format: Start / Stop / Continue
Duration: 90 minutes [fictional]

Team: Growth PM, Engineering Lead, Backend Engineer,
      Design Lead, Merchant Success Lead, QA Lead

What went well:
- Beta merchant FAQ (23 questions → 10 FAQ + 15 canned responses)
  [fictional] — reduced GA-week ticket volume significantly
- Instrumentation spec process caught subscriber email PII gap
  before GA
- Feature flag rollout (10%→100%) worked; zero rollback events

What to improve:
- Legal review started 3 weeks before GA instead of 6 weeks;
  created compliance copy crunch that delayed marketing content
- DMARC/SPF/DKIM setup: estimated 1 day, took 5 business days
  [fictional]; DNS propagation not in the timeline
- Klaviyo partner notice email sent 2 days late (no clear owner)

Previous retro actions to review (Sprint 7 retro):
- Add QA Lead to kickoff sessions — Complete
- Define escalation path for blocker tickets — In Progress
- Document infrastructure prerequisites for launches — Not Started

Need: full sprint retrospective with action items.

Output:

Retrospective: Campaigns v1.0 Build Sprint¶

Brainshelf (Consumer): Brainshelf consumer PKM app — Sprint 8 retrospective after Resurface launch

Prompt:

/retrospective

sprint 8 retro — resurface launch sprint. need to write this up.

what happened: we shipped resurface on time! first big feature in 6 months.
but we also had a timezone bug that sent the morning digest at 5am to UK/Europe
users (~340 people [fictional]). caught it 6 hours after launch, patched within 2
hours of catching it, but some users were not happy.

format: start/stop/continue. small team (7 people in the room).
2 wins, the timezone thing, and a few process issues that came up.

previous retro action items were: (1) set up staging environment email testing —
DONE, (2) add integration test for notification delivery — NOT DONE (this
contributed to the bug), (3) weekly eng/pm sync — IN PROGRESS.

Output:

Retrospective: Sprint 8 — Resurface Launch¶

Workbench (Enterprise): Workbench enterprise collaboration platform: Blueprints v1 GA post-launch retrospective

Prompt:

/retrospective

I'm facilitating the Blueprints post-GA retrospective. Here's the context:

**Session details:**
- Date: May 12, 2026
- Duration: 90 minutes
- Format: Virtual (Zoom), structured facilitation

**Attendees:** Rachel V. (PM, facilitator), Karen L. (Eng Lead), Tomás G. (Design Lead), Nate P. (Backend Eng), Aisha K. (Frontend Eng), Leo M. (Data Analyst), Sandra C. (Head of Product, observer)

**Context:**
- Blueprints v1 GA launched April 28, progressive rollout completed May 5
- 320/500 accounts active on Blueprints [fictional]; remaining 180 in onboarding pipeline
- Time-to-approved holding at 2.4 days [fictional] (target: ≤2.5)
- 3 launch-week incidents: (1) approval UX confusion -- 23 support tickets from first-time approvers who couldn't find the reject button, (2) SSO incident day 2 -- misconfigured SAML attribute mapping blocked 12 accounts for 3 hours, (3) wizard threshold rigidity -- 8 enterprise templates with 15+ sections couldn't use the wizard at all

**What went well:**
- A/B test methodology was solid; ship decision was data-driven and confident
- Progressive rollout caught the SSO issue at 10% before it hit all accounts
- Yjs co-editing performance exceeded targets (32ms p95 merge latency vs. 50ms target [fictional])
- Cross-functional coordination between eng, design, and marketing was the best it's been

**What to improve:**
- Approval UX needed more usability testing before launch
- SSO configuration was manual and error-prone; need automated validation
- Wizard threshold should be configurable, not hardcoded
- Edge-case doc was excellent but QA didn't have time to test all P2 scenarios

**Action items I want to formalize:** 5 items for v1.1 sprint planning

Please generate the full retrospective document.

Output:

Retrospective: Blueprints v1 GA Launch¶

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
Document is useful to someone who wasn't in the room

Output Format¶

Use the template in references/TEMPLATE.md to structure the output.