retrospective
Retrospective
The team that doesn't reflect doesn't improve. Retrospectives close the feedback loop.
Context
Retrospective is the skill that completes the lifecycle loop. It feeds insights from operations and evolution back into discovery, making the next cycle better than the last. Without it, teams repeat the same mistakes and miss improvement opportunities.
In a lifecycle-aware system, a retrospective is not a generic feelings exercise. It must turn concrete evidence from postmortems, reviews, and delivery outcomes into a small number of changes the team will actually route back through intake and planning.
Inputs
- incident-timeline -- produced by the preceding skill in the lifecycle
- postmortem-report -- produced by the preceding skill in the lifecycle
- review-report -- produced by the preceding skill in the lifecycle
Process
Step 1: Set the Stage (5 min)
Establish psychological safety. The retrospective must be a blame-free zone:
- "We're here to improve the system, not to assign blame"
- Check in: how is everyone feeling about the last sprint/phase?
Step 2: Gather Evidence (15 min)
What happened? Use facts and metrics before opinions:
- incident timeline and postmortem findings
- review findings that should have stopped the issue earlier
- deployment or rollback decisions
- bugs found in production
- team coordination friction that was visible during execution
Step 3: Generate Insights (15 min)
Why did it happen? Techniques:
- 5 Whys: For each problem, ask "why" five times to reach root cause
- Fishbone diagram: Categorize causes (people, process, tools, environment)
- Start/Stop/Continue: What should we begin, stop, or keep doing?
- 4Ls: Liked, Learned, Lacked, Longed-for
Stay at the system/process level. If a problem belongs in a concrete downstream skill (testing-strategy, ci-cd, incident-response, tech-debt-management), call that out explicitly.
Step 4: Decide Actions (10 min)
Select 3-5 improvements (not 20). Each must be:
- Specific: "Add integration tests for payment flow" not "improve testing"
- Assigned: One person owns it
- Timeboxed: Deadline within the next sprint/phase
- Measurable: How will we know it's done?
- Routable: It is clear whether the action should go through intake, planning, delivery, or evolution next
Prefer actions that reduce recurrence risk and improve future handoffs instead of vague morale language.
Step 5: Close (5 min)
- Recap the action items
- Appreciations: call out what went well and who helped
- Confirm which follow-up items become intake-ready work
- Rate the retrospective itself (meta-improvement)
Outputs
- retrospective-report -- produced by this skill
- improvement-actions -- produced by this skill
Quality Gate
- No more than 5 improvement actions chosen
- Each action has an owner and a deadline
- Each action has a measurable success signal
- Each action identifies its next lifecycle destination
- Actions from previous retrospective reviewed (were they completed?)
- Insights documented for future reference
Anti-Patterns
- Retro without follow-through -- The #1 killer. If actions from last retro weren't done, why would new ones be?
- Blame fest -- Degenerates into finger-pointing. Facilitator must redirect to systems thinking.
- Too many actions -- 3 completed improvements > 10 abandoned ones. Be selective.
- Skipping retro when things went well -- Good sprints have learnings too. What made it good? How do we replicate it?
- Same format every time -- Rotate formats to prevent staleness (sailboat, timeline, mad/sad/glad).
- Action items with no route back into the system -- If follow-ups never become planned work, the retro is theater.
Related Skills
- incident-response -- postmortems feed into retrospectives
- tech-debt-management -- retro surfaces debt patterns
- sprint-planning -- retro improvements feed into next sprint
- intake -- retro insights trigger new work via intake
Distribution
- Public install surface:
skills/.curated - Canonical authoring source:
skills/08-evolution/retrospective/SKILL.md - This package is exported for
npx skills add/updatecompatibility. - Packaging stability:
beta - Capability readiness:
beta
More from yknothing/prodcraft
system-design
Use when reviewed requirements or specifications are ready and the team must decide high-level architecture, component boundaries, integration seams, or brownfield coexistence strategy before API design, technology selection, or task planning.
6intake
The mandatory gateway for all new engineering work. Triage and route new products, apps, features, migrations, tech-debt, or any 'not sure where to start' request to the correct lifecycle path. Use before starting design or implementation. Do not use for ongoing tasks, specific debugging, or PR reviews.
6feature-development
Use when a reviewed task slice has tests or acceptance targets and the team must turn it into a small, mergeable implementation increment without expanding scope, breaking contracts, or hiding release-boundary risk.
6monitoring-observability
Use when a live service or newly delivered release needs actionable telemetry, dashboards, and alerts that expose real user-impactful boundaries, especially when brownfield coexistence rules, unsupported-flow safety, rollback health, or queue/backfill behavior must be visible before incidents escalate.
6incident-response
Use when a live production issue needs coordinated containment, severity triage, stakeholder communication, and evidence capture, especially when a recent release, brownfield coexistence rules, rollback decisions, or unresolved contract boundaries must be handled before root-cause work.
6task-breakdown
Use when reviewed architecture or API contracts must be decomposed into implementation-ready work items, especially when sequencing, reversible brownfield increments, dependency mapping, and vertical slices must be explicit before coding begins.
6