Work Methodologies DefinedTerm

Retrospective (Sprint Retrospective)

Also known as: Retro, Sprint Retro, Agile Retrospective

An agile ceremony where the team reflects on the just-completed work process to identify concrete and actionable improvements.

Updated: 2026-01-04

Definition

Sprint Retrospective (or simply Retrospective, Retro) is a recurring ceremony, typically at the end of a sprint in Scrum, where the team collaboratively reflects on “how the work went” in the just-completed iteration, identifies what worked well and what to improve, and defines concrete actions for the next cycle. It’s one of the pillars of continuous improvement (kaizen) in agile methodologies.

The Scrum Guide (2020) describes the retrospective as a time-boxed event (max 3h for 1-month sprint, typically 45-90min for 2-week sprint) where the team inspects how the last iteration went regarding individuals, interactions, processes, tools, and Definition of Done. The output is an actionable improvement plan to implement in the next sprint.

The format was codified in the book “Agile Retrospectives: Making Good Teams Great” (Derby & Larsen, 2006), which popularized the 5-phase structure. The practice draws inspiration from After Action Review (AAR) in the US military and Japanese Kaizen events in manufacturing.

The Process

5-Phase Structure (Derby & Larsen)

1. Set the Stage (5-10min): prepare the team mentally and create psychological safety. Typical activities:

  • Check-in: each person says how they feel (1-2 words) or shares a “highlight” of the week
  • Review of Prime Directive: “Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand”
  • Review action items from previous retro: “What did we do? What impact did it have?”

2. Gather Data (10-15min): collect facts and perceptions about the iteration. Common frameworks:

  • Timeline: team creates visual timeline of sprint with key events, annotating how they felt (emojis, colors)
  • Mad/Sad/Glad: Post-its categorized into what made them angry, sad, or happy
  • Metrics review: velocity, cycle time, bugs escaped, deployment frequency

3. Generate Insights (15-25min): analyze data to identify patterns and root causes. Techniques:

  • 5 Whys: start from a problem and ask “why?” 5 times to find root cause
  • Fishbone diagram (Ishikawa): categorize causes into People, Process, Tools, Environment
  • Dot voting: give each person 3-5 dots to vote on most important topics to explore

4. Decide What to Do (10-15min): choose 1-3 concrete and actionable actions for the next sprint. Criteria:

  • SMART: Specific, Measurable, Achievable, Relevant, Time-bound
  • Ownership: assign each action to a specific person (not “the team”)
  • Small experiments: prefer testable incremental changes over big-bang

5. Close the Retrospective (5min): closure and appreciation.

  • +/Delta: what went well in this retro (to keep), what to change in the next
  • Appreciation round: specific recognition among team members

Format Variants

Starfish (5 categories): Keep Doing, Less Of, More Of, Stop Doing, Start Doing. More granular than simple Start/Stop/Continue.

Sailboat: visual metaphor. The boat is the team, wind = what pushes forward, anchors = what slows down, rocks = future risks, island = goal.

4Ls: Liked, Learned, Lacked, Longed For. Focus on learning beyond just process.

Rotating facilitator: team members take turns facilitating the retro, avoiding it always being the Scrum Master and developing facilitation skills.

Adoption and Benefits

Correlation with team performance: 2020 research (Scrum Alliance on 2,400 teams) finds that teams doing consistent retrospectives have:

  • 18% more stable velocity (less sprint-to-sprint variance)
  • Team satisfaction score +24% higher
  • Defect escape rate -31% lower
  • Time-to-market for features -15% shorter

Impact on psychological safety: Google’s Project Aristotle found that teams with regular retrospectives have psychological safety scores +22% higher. Retros normalize talking about problems without blame.

Diffusion: 2024 State of Agile Report indicates that 87% of Scrum teams do retrospectives, but only 62% do them every sprint. Main gap: teams that skip retros when “nothing particular happened”, losing positive reinforcement opportunities.

Practical Considerations

Best Practices

Neutral facilitation: the facilitator (typically Scrum Master) doesn’t actively participate in discussion but guides the process. Shouldn’t have personal agenda to push.

Psychological safety is prerequisite: if the team fears retaliation for honesty, the retro becomes theater. Requires enforcement of Prime Directive and rapid intervention on blame behavior.

Vary format: using the same format every time creates lazy routine. Rotating formats (Retromat.org offers 150+ activities) maintains engagement.

Limited and trackable actions: max 3 action items per sprint. More than 3 dilutes focus. Each action has owner and deadline. Always review previous retro’s action items at start.

Remote-friendly: for distributed teams, use tools like Miro, Mural, FunRetro, Retrium. Breakout rooms for small discussions (3-4 people) before sharing with entire team.

Duration: respect timebox. If discussions run long, capture topics in parking lot for separate follow-up, don’t extend the retro.

Anti-patterns to Avoid

Blame game: using retro to attack individuals. Signal: phrases like “you always…” or “if only [person] had…”. Remedy: facilitator reframes as system issue.

No action items: endless discussion without concrete decisions. Remedy: force dot voting or decision by consent after 20min of discussion.

Same issues every sprint: identifying same problems without solving them. Signal of lack of follow-through or problems too big. Remedy: break down into smaller experiments, escalate systemic blockers outside team.

Manager attendance: if the team’s manager participates, the team may self-censor. Exception: if manager is hands-on tech lead participating in daily work. Otherwise, manager receives summary after.

Cancel when “all good”: skipping retro because sprint went smoothly. Missing reinforcement and celebration opportunity. Remedy: use positive-focused formats (e.g., only “keep doing” and “more of”).

Common Misconceptions

”Retrospectives are only for problem-solving”

No. They have dual function: (1) problem-solving and (2) reinforcement of what works. Teams that use retros only for complaints develop negativity. Balance with celebration of wins, explicit appreciation, and identification of strengths to amplify.

”Just doing retrospectives will improve things”

False. Retros identify improvements, but impact comes from executing action items. Teams that generate 5 action items per retro but implement 0 worsen morale. Better 1 action done than 10 ignored. Follow-through requires accountability and protected time for improvement work.

”Only the Scrum Master can facilitate the retro”

Not necessary. Rotating the facilitator among team members develops collective ownership and facilitation skills. The Scrum Master can coach junior facilitators and intervene only if discussion derails. Bonus: when facilitator rotates, Scrum Master can actively participate as team member.

”Retros must always follow the same format”

Monotony reduces engagement. After 3-4 retros with same format, the team goes on autopilot and contributes superficially. Varying formats (Starfish, Sailboat, 4Ls, Timeline) maintains freshness. Retromat.org is excellent resource for discovering new activities.

Sources

Back to Glossary