Retrospective

Retrospective

Overview

A retrospective is a structured reflection on what happened, why, and what to do differently next time. Done well, retros turn experience into improvement. This skill covers multiple retro formats, facilitation techniques, and turning findings into action.

When to Use

• After a product launch or major release
• At the end of a sprint or project
• When the team is stuck in the same patterns
• Building a culture of continuous improvement
• Don't use for: finger-pointing (that's a postmortem, not a retro), when the team is too burned out (fix the burn-out first)

Instructions

1. Choose the Format

Start/Stop/Continue (simple, gets results fast):

• Start: What should we start doing?
• Stop: What should we stop doing?
• Continue: What should we keep doing?

4Ls (good for medium-complexity projects):

• Liked: What worked well?
• Learned: What did we learn?
• Lacked: What was missing?
• Longed For: What do we wish we had?

Sailboat (good for emotional topics):

• Wind: What pushed us forward?
• Anchor: What held us back?
• Rocks: What risks do we see ahead?
• Sun: What are we excited about?

2. Gather Data (5 min per person)

• Each person writes their observations independently
• One observation per sticky/card
• Be specific: reference events, dates, and decisions — not vague feelings
• Timebox: 5 minutes max per section

3. Cluster and Discuss (10 min)

• Group related observations
• Discuss the most-voted clusters
• Focus on systems and processes, not people
• Ask "What led to that?" to find root causes

4. Identify Action Items (10 min)

For each key finding:

• Action: What specifically will we change?
• Owner: Who's responsible?
• Timeline: When will it be done?
• Success criteria: How will we know it worked?

5. Follow Up (next retro)

• Start the next retro by reviewing action items from the previous one
• Were they completed? Did they help? If not, why?

Sample Output

Format: Start/Stop/Continue for a Feature Launch

Stop:

• Stop shipping on Friday afternoon (3 deployed bugs caught over the weekend)
• Stop merging before code review passes

Start:

• Start writing release notes mid-sprint, not the night before launch
• Start doing pre-launch load testing

Continue:

• Continue daily standups — they kept us aligned
• Continue design review — caught UI issues early

Top Action Item: Ship on Tuesdays/Thursdays only. ✅ Owner: Dev lead. Done: Next sprint.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: uthumany
• Source: uthumany/uthy-legacy-os
• License: MIT
• Homepage: https://uthumany.github.io/uthy-legacy-os/

Install and usage instructions live in the source repository linked above.