---
title: "Retrospective"
description: "Facilitates and documents a team retrospective capturing what went well, what to improve, and action items. Use at the end of sprints, projects, or milestones to reflect and improve team practices."
generated: true
source: scripts/generate-skill-pages.py
tags:
  - Iterate
  - reflection
---

:::note[Quick facts]
**Phase:** Iterate | **Version:** 2.0.0 | **Category:** reflection | **License:** Apache-2.0
:::

**Try it:** `/retrospective "Your context here"`

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:

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

<!-- 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

| 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

<!-- 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 -->

| 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

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

| 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

<!-- 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

| 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

<!-- 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].*

## Example Output

<details>
<summary>Retrospective: Sprint 14 . Payment Feature Launch</summary>

# 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.*

</details>

## Real-World Examples

See this skill applied to three different product contexts:

<details>
<summary>Storevine (B2B): Storevine B2B ecommerce platform . Campaigns v1.0 build sprint retrospective</summary>

**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

</details>

<details>
<summary>Brainshelf (Consumer): Brainshelf consumer PKM app . Sprint 8 retrospective after Resurface launch</summary>

**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

</details>

<details>
<summary>Workbench (Enterprise): "Workbench enterprise collaboration platform: Blueprints v1 GA post-launch retrospective"</summary>

**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

</details>

## 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.
