Setting the Stage in a Sprint Retrospective

Setting the stage in a retrospective: open with a clear goal, working agreements and a check-in so every person speaks early and is ready to reflect.

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

Setting the stage is the first of the five phases in Esther Derby and Diana Larsen's retrospective structure, and its job is to get the team ready to reflect together. Retromat's summary of the phases describes it in two lines: set the goal, and give people time to "arrive" and get into the right mood (Retromat). The Five-Step Retrospective Framework page covers the full meeting and how to run a sprint retrospective end to end. This skill covers only the opening.

A sprint retrospective opening does three things. It tells people what this session is for and how long it will take. It reminds them of how the team has agreed to talk to each other. It gets every voice into the room with a short check-in, so that speaking up later feels normal. MindTools' summary of the five steps describes the same opening: welcome the team, explain the goals and duration, make clear that the meeting is not about blame, and ask each person for a one-word summary of the sprint (MindTools).

The phase is short, but the rest of the meeting depends on it. If people hold back in the first minutes, the gather-data phase collects a thin, cautious account of the sprint, and the insights built on it are thin too. GitLab's engineering handbook puts a safe environment first among the requirements for an efficient retrospective and explains that without it "issues may go unmentioned" (GitLab Handbook). Google's research on team effectiveness found psychological safety, "a shared belief held by members of a team that the team is safe for interpersonal risk taking", to be the most important of the dynamics it studied (Google re:Work).

The opening is also where the facilitator reads the room. A check-in often shows that the team is tired, divided or worried about something specific. That is information the facilitator needs before the data phase, because it may mean changing the plan: spending longer on a difficult event, choosing a quieter activity, or naming a tension openly. Treat the opening as the first data you collect about the sprint, gathered in a form everyone can share safely.

How It Works

The phase has four parts, run in this order: purpose, agreements, check-in and transition.

The purpose statement names the scope and the time. "The last two weeks" is a scope. "The last two weeks, with a focus on how the release went" is a sharper one, and it tells people what kind of data to bring to mind. State the timebox and the agenda in one or two sentences so nobody wonders whether there will be time to raise their issue.

Working agreements are the team's ground rules for the conversation. Atlassian describes working agreements as "shared norms for how a team will work together" and recommends revisiting them when members join or circumstances change (Atlassian). For a retrospective, the useful agreements are about how people speak: from their own experience, about the process rather than individuals, one conversation at a time, and what stays in the room. Many teams also read Norm Kerth's Prime Directive at this point, which asks everyone to believe that people "did the best job they could, given what they knew at the time" (Retrospective Wiki). Read it only if the team finds it useful. A ritual nobody believes weakens the other agreements.

The check-in gives every person a turn to speak within the first few minutes. Common retrospective check-in activities include a one-word description of the sprint, a question tied to the session's focus, and ESVP, where people anonymously say whether they feel like an explorer, shopper, vacationer or prisoner and the results are shown as a histogram (FunRetrospectives). Retrium's list of set-the-stage activities adds Constellations and a review of the previous action plan (Retrium).

The transition closes the phase. Summarize what the check-in showed in a sentence, say what happens next, and move on. Keep the whole opening short compared with the rest of the meeting; Retrium's sample 60-minute plan gives it 10 minutes and Atlassian's gives it 5 (Retrium, Atlassian).

Remote sessions need a little more care in this phase. People join from different contexts and are easier to lose on a call, so use a check-in that asks everyone to type or speak within the first minutes, and agree on camera, chat and hand-raising norms as part of the working agreements. The second edition of Agile Retrospectives adds guidance for remote and hybrid teams (Pragmatic Bookshelf).

Step-by-Step Guide

Step 1: Prepare the space before people arrive

Set up the room or the digital board before the start time, with the agenda, the working agreements and the check-in ready to use. Test any tools, links or voting features so the first minutes are not spent on logistics. For remote sessions, open the call a few minutes early. Decide in advance how you will handle a check-in that shows low trust, so you are not improvising under pressure.

Step 2: State the purpose, scope and timebox

Welcome people and say, in plain words, what this retrospective is for and what period it covers. If there is a focus, such as a release or a new way of working, name it. Give the end time and show the agenda by phase. Ask whether anyone needs the session to cover something that is missing, and adjust the scope now rather than halfway through.

Step 3: Review the working agreements

Show the team's agreements and ask whether they still hold or need a change. If the team has none, propose three or four about how people talk in the retrospective and ask the group to amend them. Read the Prime Directive if the team uses it. Keep this brief for an established team, and spend longer on it for a new team or after a conflict.

Step 4: Run a short check-in

Choose a check-in that fits the mood you expect. A one-word round works for most sprints. ESVP or another anonymous poll works better when you suspect people are disengaged or wary of speaking, because the result is shared without naming anyone (FunRetrospectives). Everyone answers, including the facilitator if they are a team member, and nobody comments on individual answers.

Step 5: Read the result and adjust the plan

Look at what the check-in shows as a group. If most people are neutral or positive, go ahead with the plan. If the check-in shows frustration, fatigue or a split, acknowledge it without judging it, and consider changing the next activity or giving more time to a specific event. A wall of prisoners in an ESVP is a reason to ask what would make the session worth their time.

Step 6: Transition to gathering data

Summarize the opening in one sentence, restate the focus, and introduce the next activity. Explain what people will do and how long it will take. A clear transition tells the team the opening is over and the reflection has started. Keep to the time you announced, which shows that the timebox is real.

Best Practices

• Open with the goal of the session, stated in terms of what the team will leave with. People engage more when they know the retrospective will end in a decision, and the Scrum Guide describes the event's purpose as planning "ways to increase quality and effectiveness" (Scrum Guide).
• Get every voice in early. A round where each person says one word takes little time and makes the next contribution easier for quiet members.
• Keep a neutral facilitator. GitLab recommends "an impartial moderator" and notes that when the moderator seems to have a stake, people may not feel safe to voice dissent (GitLab Handbook).
• Think about who is in the room. The Agile Alliance notes that the presence of a manager "may inhibit discussion of performance issues" (Agile Alliance). Agree attendance with the team before the session.
• Vary the check-in so it keeps producing honest answers. Repeating the same question every sprint invites the same polite reply.
• Revisit the working agreements when the team changes, as the Atlassian working agreements play recommends after onboarding or organizational change.

Common Mistakes

• Skipping the opening to save time: The minutes saved are usually lost later, when people hold back during data gathering. Keep the opening short, but always run it.
• Letting the opening turn into the discussion: A check-in answer can start a debate about the sprint. Note the topic, promise to return to it in the data phase, and finish the round.
• Reading agreements nobody believes: Rules read aloud by habit carry no weight. Ask the team to confirm or change them, and drop any the team does not follow.
• Ignoring what the check-in shows: If the check-in reveals low energy or distrust and the facilitator carries on as planned, people learn that their answers do not matter. Acknowledge the result and adjust.
• Running the same check-in forever: Familiar questions get automatic answers. Rotate activities from a library such as Retromat to keep them useful.

References

• Examples: Worked examples and scenarios
• FAQ: Frequently asked questions
• Parent Method: Five-Step Retrospective Framework

Related Skills

• Gathering Data in Retrospectives
• Choosing Retrospective Activities and Exercises
• Building a Reusable Sprint Retrospective Template
• Closing a Retrospective Meeting Effectively

Sources

• Retromat: What is a retrospective
• MindTools: Sprint Retrospectives in Agile Project Management
• GitLab Handbook: Group Retrospectives
• Google re:Work: Understand team effectiveness
• Atlassian Team Playbook: Working agreements
• Retrospective Wiki: The Prime Directive
• FunRetrospectives: ESVP
• Retrium: The Five Phases of a Successful Retrospective
• Atlassian Team Playbook: Sprint Retrospective
• Agile Alliance Glossary: Heartbeat Retrospective
• The Scrum Guide
• Pragmatic Bookshelf: Agile Retrospectives, Second Edition

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