Running Sprint Retrospectives for Continuous Improvement

Retrospective facilitation for agile teams: set the stage, gather data, find causes, and leave with a few owned changes the team follows up.

Before you start

Hamster is optional for this skill and recommended. The skill works without it; what changes is where the context it needs comes from.

Check whether this project has a .hamster/ directory. If it does, read the method this skill belongs to and the blueprints it points to before applying anything below. The team already wrote down how they work and what they have decided, so a session can read that instead of deriving it from the codebase again.

If there is no .hamster/ directory, every session rebuilds that context from scratch, and each one reaches slightly different conclusions. Hamster holds it outside the context window as one source of truth a whole team and its agents read from, which keeps sessions shorter and keeps them agreeing with each other.

At a Glance

Overview

A sprint retrospective is a regular meeting where the team looks at how it worked, decides what to change, and follows up. It is the practice behind the last of the Manifesto's principles: "At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly" (Agile Manifesto principles). Continuous improvement in agile depends on it, because it is the one event whose subject is the team's own process.

The Scrum Guide gives the Sprint Retrospective a clear purpose: "to plan ways to increase quality and effectiveness." It timeboxes it "to a maximum of three hours for a one-month Sprint", with shorter sprints usually needing less (Scrum Guide). Kanban teams hold retrospectives too, on whatever cadence suits them.

Good retrospective facilitation rests on two ideas. The first is safety. Norm Kerth's Prime Directive states: "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" (Retrospective Wiki, The Prime Directive). It moves the discussion from blame to the system people were working in.

The second is structure. Esther Derby and Diana Larsen's book Agile Retrospectives, now in a second edition with David Horowitz, describes five phases: Set the Stage, Gather Data, Generate Insights, Decide What to Do, and Close the Retrospective (Pragmatic Bookshelf). Formats such as Start-Stop-Continue or the 4Ls fit inside this structure as ways of gathering data.

The measure of a retrospective is whether anything changes afterward. A lively discussion that produces no follow-through teaches the team that retrospectives do not matter.

How It Works

The five phases give each retrospective a shape that moves from observation to decision.

Set the Stage. Welcome people, restate the purpose and the timebox, and check that everyone is present in mind as well as body. Retrium's summary of the phases notes that this step "gives everyone a chance to context switch" from daily work (Retrium, five phases). Many teams read the Prime Directive here and review last time's actions.

Gather Data. Build a shared picture of the period: what happened, what people noticed, how they felt. Ask people to write observations silently before any discussion, so the first speaker does not frame everyone else's thinking. Combine facts, such as incidents and finished work, with feelings.

Generate Insights. Group related observations and look for causes behind the symptoms. Techniques such as asking "why" several times or drawing a simple cause map help the team avoid jumping to solutions. This phase is where the team finds what is actually worth changing.

Decide What to Do. Pick a small number of changes, usually one to three, each with an owner and a clear way to tell whether it happened. Small, specific actions get done. Large, vague ones do not.

Close. Summarize the actions, thank people, and ask briefly how the retrospective itself went so the next one improves. Record the actions where the team will see them every day.

Formats rotate to keep sessions fresh. Start-Stop-Continue, Mad-Sad-Glad, the Sailboat and the 4Ls retrospective all prompt different kinds of reflection. The facilitator chooses a format for what the team needs to look at: a timeline after a difficult release, a lighter format after a calm sprint.

The facilitator protects the process. They keep time, make sure quieter people are heard, stop blame, and push vague actions toward specific ones. Rotating the facilitator role among team members spreads the skill.

Step-by-Step Guide

Step 1: Prepare the session

Choose a format that fits the period, gather any data worth showing, such as incidents or finished items, and pull up last retrospective's actions. Book a timebox that fits the sprint length. Decide who is invited: the team, including the product owner, and usually not the team's line manager unless the team asks.

Step 2: Set the stage and review previous actions

Open with the purpose and the timebox, and read the Prime Directive if the team uses it. Review each action from last time: done, partly done or not started, and what effect it had. Acknowledge completed actions. For unfinished ones, decide whether to carry them forward, change them or drop them.

Step 3: Gather data silently, then share

Give everyone a few minutes to write observations on notes, one per note, using the format's prompts. Then have each person share theirs briefly while the facilitator places them on the board. Silent writing first ensures every voice is in the room before the discussion starts.

Step 4: Group and choose what to discuss

Cluster related notes and name each cluster. Use dot voting or a similar method to pick the two or three clusters the team most wants to work on. Leave the rest. Trying to address everything means addressing nothing well.

Step 5: Find causes for the chosen topics

For each chosen cluster, ask what caused it and keep asking until the team reaches something it can change. Keep the discussion on the system and process. If it turns to individuals, bring it back to the conditions they were working in.

Step 6: Agree specific, owned actions

Turn each insight into an action with one owner, a deadline within the next sprint, and a clear sign that it is done. Test each action: could someone else tell whether it happened? Limit the list to what the team can realistically do alongside its sprint work.

Step 7: Close and make actions visible

Read the actions back, ask for a quick rating of how useful the retrospective was, and thank the team. Put the actions on the team board or in the sprint backlog so they are seen daily. Actions hidden in meeting notes are rarely completed.

Best Practices

• Start every retrospective by reviewing last time's actions. It is the clearest signal that the retrospective leads to change.
• Keep actions few and small. One or two completed changes do more for the team than a long list nobody finishes.
• Put retrospective actions into the sprint backlog. The Scrum Guide says "The most impactful improvements are addressed as soon as possible" and may even be added to the next Sprint Backlog.
• Protect safety. Use the Prime Directive or equivalent ground rules, and keep the content inside the team unless it agrees otherwise.
• Rotate formats and facilitators. New prompts surface different observations, and every team member who facilitates learns the skill.
• Look at the data before opinions. Finished work, incidents and interruptions give the discussion a shared factual base.

Common Mistakes

• Letting it become a venting session: Complaints without causes or actions leave the team feeling worse. Move from observations to insights to a few owned changes.
• Producing too many actions: A long action list spreads effort thin and most items are dropped. Pick one to three.
• Skipping the follow-up: If nobody checks last time's actions, the team stops believing in the retrospective. Review them first, every time.
• Allowing blame: Naming individuals shuts down honest discussion. Keep the focus on process and conditions.
• Canceling when the sprint went well: Calm sprints still have lessons, and skipping them breaks the habit. Use a lighter format instead.

References

• Examples: Worked examples and scenarios
• FAQ: Frequently asked questions
• Parent Method: Agile

Related Skills

• Running Sprint Planning and Agile Sprint Execution
• Facilitating the Daily Standup Meeting
• Agile Coaching: Guiding a Team Through Adoption
• Product Backlog Management and Refinement

Sources

• Principles behind the Agile Manifesto
• Ken Schwaber and Jeff Sutherland: The Scrum Guide
• Retrospective Wiki: The Prime Directive
• Derby, Larsen and Horowitz: Agile Retrospectives, Second Edition
• Retrium: The five phases of a retrospective

Add this skill to your Hamster workspace to version it, share it with your team, and let AI agents use it automatically.