Gathering Data in Retrospectives: Questions and Techniques

Retrospective data gathering: the questions, techniques and prepared metrics that give a team one shared picture of the sprint before it explains anything.

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

Gathering data is the second phase of the Five-Step Retrospective Framework. Its job is to build one shared picture of what happened in the sprint before anyone tries to explain it. Retromat's summary of the phase is "Help everyone remember; Create a shared pool of information (everybody sees the world differently)" (Retromat). That last point is why the phase exists. Each person saw a different slice of the sprint, and a team that skips to causes ends up arguing from different sets of facts.

Good retrospective data has two kinds of content. Hard data covers events and measurements: what was planned and delivered, incidents, blocked work, changes in scope, and the status of the last retrospective's actions. Soft data covers how the sprint felt: where people were frustrated, energized, confused or proud. Both are facts about the sprint. A team that looks only at numbers misses the friction that explains them, and a team that looks only at feelings misses patterns nobody noticed.

Most retrospectives lean heavily on memory. Christoph Matthies and Franziska Dobrigkeit reviewed retrospective activities and found that most "rely on team members experiences and neglect to take existing project data into account" (Matthies and Dobrigkeit). Bringing a small, prepared set of data into the room corrects for recency and for whoever tells the most vivid story.

The phase also sets up fairness. Quiet writing before discussion lets everyone contribute before the most confident voice frames the sprint. Anonymous input helps when a topic is sensitive. The facilitator's aim is completeness: every part of the sprint, and every person, represented on the wall before the group moves on.

This skill covers which sprint retrospective questions to ask, which techniques to use, how to prepare data, and how to tell when the picture is complete enough to start generating insights.

How It Works

The phase runs in three moves: prepare, collect, and check.

Preparation happens before the meeting. Decide what hard data the team should see, and keep it small: a few charts or numbers that bear on the sprint's goal, plus the list of actions from last time. The Scrum Guide says the retrospective inspects "individuals, interactions, processes, tools, and their Definition of Done" (Scrum Guide), which is a useful checklist for what might be relevant. Prepare the material so it can be read at a glance, and avoid turning the phase into a metrics presentation.

Collection happens in the room. Choose one activity that fits the sprint. A timeline, where people place key events along the sprint and mark how they felt, suits long or eventful sprints. A feelings board such as Mad Sad Glad suits sprints where mood matters. GitLab's handbook gives both as examples: collecting facts "by constructing a timeline, soliciting impressions" or asking what made people mad, sad or glad (GitLab Handbook). Retrium's list of gather-data activities adds Lean Coffee, where the group proposes and votes on topics (Retrium). A data-driven timeline, as FunRetrospectives describes it, lets the team connect events to outcomes across functions (FunRetrospectives).

Good agile retrospective questions are open, specific and neutral. "What happened when the release slipped?" invites facts. "Why did the release slip?" invites causes and belongs to the next phase. "Who caused the slip?" invites blame and has no place in the meeting. Useful retrospective questions for teams include: what happened that you did not expect, where did you wait on something, when did you feel most productive, and what did the data show that surprised you.

Checking closes the phase. Once the notes are up, read them aloud, group duplicates lightly, and look for gaps: a week of the sprint with no notes, a role that has not contributed, a known event nobody mentioned. Ask directly about the gaps. Light grouping here makes the insight phase faster, and Nielsen Norman Group's description of affinity diagramming shows how notes are clustered and labeled by theme (Nielsen Norman Group). Deep analysis waits for the next phase.

Step-by-Step Guide

Step 1: Prepare a small set of data

Before the meeting, pull the few measures that relate to the sprint goal, a list of notable events, and the status of the previous retrospective's actions. Keep it to what fits on one screen or one sheet. Check the numbers for obvious errors so the meeting does not turn into a debate about the data itself. Share it in advance if the team likes to read before meetings.

Step 2: Choose an activity that fits the sprint

Match the activity to what you expect the sprint to hold. Use a timeline for a long sprint, a release or an incident, because it restores the order of events. Use a feelings board when morale is the story. Use a structured prompt such as the 4Ls or Start Stop Continue when the team wants a familiar format. Avoid repeating the same activity every sprint, since familiar prompts produce familiar answers.

Step 3: Give quiet time to write

Ask everyone to write notes on their own first, one observation per note. Silent writing lets everyone record their own view before discussion starts, so one person's story does not frame everyone else's. Offer anonymous input if the sprint included something sensitive. The facilitator writes only if they are also a team member.

Step 4: Ask specific, neutral questions

Use questions that invite facts and experiences and hold back questions about causes. Ask what happened, when, and how it felt, and leave why for the next phase. Prompt for the parts of the sprint that are easy to forget, such as the first days and work that was dropped. When the data shows something, ask people to add what they saw around it.

Step 5: Read back and lightly group the data

Put all notes on the board and read them out, or invite each person to present theirs briefly. Group obvious duplicates and name clusters in a word or two. Resist interpreting the clusters yet. Point out where hard data and experiences support each other and where they disagree, because those contrasts are useful in the insight phase.

Step 6: Check for gaps and missing voices

Scan the board for gaps in time, topic or people. Ask whether anything important is missing, and invite contributions from anyone who has added little. When the group agrees the picture is complete enough, summarize it in a sentence or two and move to generating insights.

Best Practices

• Bring a little real data every time. Research by Matthies and Dobrigkeit argues that data-informed activities are advantageous and underused in retrospectives.
• Separate what happened from why it happened. Park explanations on a side list and return to them in the insight phase.
• Collect feelings alongside facts. Frustration and energy explain behavior that numbers alone cannot.
• Start with silent writing, then discuss. It gets every person's observations onto the wall and protects quieter team members.
• Include the status of the last retrospective's actions. Ben Linders usually starts his retrospectives by checking whether the previous actions are finished (Ben Linders).
• Vary the activity. Libraries such as Retromat exist so you do not run the same exercise every sprint.

Common Mistakes

• Jumping to causes during data gathering: When someone explains an event, the discussion narrows before all the facts are in. Note the explanation for later and keep collecting.
• Relying only on memory: Memory favors recent and dramatic events. Add a timeline or prepared data so the whole sprint is covered.
• Turning the phase into a metrics review: A long presentation of charts leaves no time for experiences. Show a few numbers that matter and let the team add context.
• Letting one voice set the story: If the first speaker frames the sprint, others fill in details around their view. Use silent writing and round-robin sharing.
• Moving on with gaps: A quiet week or a silent person can hide the most important data. Check coverage before leaving the phase.

References

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

Related Skills

• Setting the Stage in a Sprint Retrospective
• Generating Insights from Retrospective Data
• Choosing Retrospective Activities and Exercises
• Tracking Retrospective Action Items Across Sprints

Sources

• Retromat: What is a retrospective
• Matthies and Dobrigkeit: Experience vs Data
• The Scrum Guide
• GitLab Handbook: Group Retrospectives
• Retrium: The Five Phases of a Successful Retrospective
• FunRetrospectives: Timeline driven by data
• Nielsen Norman Group: Affinity Diagramming
• Ben Linders: Getting Retrospective Actions Done
• Retromat: About

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