Generating Insights from Retrospective Data

Generate insights in a retrospective: cluster the sprint data, find patterns and use the 5 Whys or a fishbone to reach causes the team can act on.

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

Generating insights is the third phase of the Five-Step Retrospective Framework and the point where the team moves from what happened to why it happened. Retromat's summary lists the phase's questions as "Why did things happen the way they did?; Identify patterns; See the big picture" (Retromat). GitLab's engineering handbook describes the same step as working together "to identify patterns or causal relationships" once all the facts are on the table (GitLab Handbook).

This phase decides the quality of everything that follows. Actions built on a symptom treat the symptom: "add a review reminder" fixes nothing if reviews are slow because nobody owns them. Actions built on a real cause change the conditions that produced several symptoms at once. The phase is where the team earns the right to decide.

Retrospective insights are explanations the team agrees on. An observation says that deploys were delayed three times. An insight says that each delay came from a manual step only one person knows how to do. An insight usually connects several notes on the board, points to a condition the team could change, and survives the question "is that really why?"

Generating insights is hard to do well under time pressure. The pull is to accept the first plausible explanation, usually the most visible one, and move on to solutions. Research on retrospective activities by Christoph Matthies and Franziska Dobrigkeit found evidence for the claimed benefits of activities in most studied cases but also found that applying them "led to new headaches arising" (Matthies and Dobrigkeit), which is a reminder to choose an analysis technique that fits the data and the time available.

This skill covers how to turn clustered data into themes, how to run root cause analysis in a retrospective with techniques such as the 5 Whys and a fishbone diagram, and how to tell an insight from an observation or a solution in disguise.

How It Works

The phase runs in three moves: cluster, choose, and dig.

Clustering turns many notes into a few themes. Nielsen Norman Group describes affinity diagramming as "organizing related observations, ideas, concepts, or findings into distinct clusters", then naming each cluster (Nielsen Norman Group). In a retrospective, the gather-data phase has usually done light grouping already. Here the team finishes it: merges near-duplicates, names each theme in a short phrase, and looks for themes that appear in both the hard data and the experiences.

Choosing narrows the analysis to what matters most. There is rarely time to dig into every theme. A quick vote or a facilitator's proposal picks the one to three themes with the most weight: the ones that cost the most, recur, or worried the most people.

Digging looks for causes behind the chosen themes. Retrium lists 5 Whys and Force Field Analysis as insight activities (Retrium). The 5 Whys asks why repeatedly until the team reaches a cause it can act on; the Lean Enterprise Institute stresses that "the specific number five is not the point" (Lean Enterprise Institute). A fishbone diagram, the cause-and-effect chart created by Kaoru Ishikawa, sorts possible causes into categories, such as the manufacturing set of machine, method, material, measurement and manpower (Wikipedia). A software team can adapt the categories to people, process, tools and environment, which keeps it from fixating on one kind of cause. Force field analysis lists the forces that pushed an outcome forward and those that held it back.

Look across themes as well as within them. Two themes that look separate often share a cause: late reviews and missed sprint goals may both come from too much work in progress. Also look at what went well. MindTools' summary of the phase includes acknowledging successes alongside problems (MindTools), and understanding why something worked helps the team repeat it.

The phase ends with a short list of insights, each written as a sentence the team agrees with. Solutions that came up along the way are kept on a side list for the decide phase.

Step-by-Step Guide

Step 1: Mark the shift from what to why

Tell the team the phase has changed: the question now is why things happened. Restate the ground rule that the discussion is about the process and conditions, not individuals. Point to the clusters from the data phase as the starting material. Set a timebox so people know the phase will end with a decision about what matters.

Step 2: Finish clustering and name the themes

Ask the team to merge duplicates and group related notes. Give each cluster a short, neutral name that describes the theme without judging it. Check whether any cluster mixes several different issues and split it if so. Aim for a handful of themes that everyone can see at once.

Step 3: Choose the themes to analyze

Pick the one to three themes with the most weight. Use a quick vote, or propose a choice and ask for objections. Consider cost, recurrence and how many people raised the issue. Say explicitly which themes are being set aside so nobody feels ignored.

Step 4: Dig into causes

For each chosen theme, use a technique that fits it. Use the 5 Whys for a clear chain of events, a fishbone for a problem with several possible contributing causes, and force field analysis when the team needs to see what helped and what hindered. Keep asking whether each answer is supported by the data on the board. Stop when the team reaches a cause it could change or influence.

Step 5: Look for connections across themes

Step back and compare the causes. Ask whether any cause appears under more than one theme. Shared causes are often the most valuable insights, because changing one condition improves several things. Also note causes of what went well that the team wants to keep.

Step 6: Write the insights and park the solutions

Write each insight as one sentence that explains a pattern and names a cause. Read them back and check that the team agrees with each one. Move any proposed fixes to a side list for the decide phase. Close the phase with a short summary of the insights, which becomes the input for deciding what to do.

Best Practices

• Keep solutions out of this phase. Write them on a side list, since discussing fixes before the cause is clear narrows the analysis too early.
• Ground every cause in the data. When someone proposes a cause, ask which notes or numbers support it, and treat unsupported causes as hypotheses.
• Use the 5 Whys flexibly. The Lean Enterprise Institute says the aim is to keep asking until the root cause is reached, whatever the count.
• Examine successes too. Understanding why something went well is as useful as understanding a failure, and it balances the mood of the meeting.
• Look for causes the team controls. Diana Larsen's Circles and Soup sorts issues by whether the team controls them, can influence them, or can only choose how to respond.
• Timebox the analysis and protect it. It is the phase most often squeezed by a long data phase, and a short, focused analysis is better than none.

Common Mistakes

• Treating the first explanation as the cause: The most visible explanation is often a symptom. Ask why again and check the answer against the data.
• Analyzing every theme shallowly: Spreading time across all themes produces a list of surface causes. Pick the few that matter and go deep.
• Letting analysis turn into blame: Questions that end in a person's name stop the analysis. Redirect to the conditions that made the outcome likely.
• Writing solutions as insights: "We need more tests" is a proposal. Ask what condition it responds to and write that condition down as the insight.
• Running out of time: When the data phase overruns, the analysis gets squeezed. Protect its timebox and shorten the data phase instead.

References

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

Related Skills

• Gathering Data in Retrospectives
• Decide What to Do: Prioritizing Retrospective Actions
• Choosing Retrospective Activities and Exercises

Sources

• Retromat: What is a retrospective
• GitLab Handbook: Group Retrospectives
• Matthies and Dobrigkeit: Towards Empirically Validated Remedies for Scrum Retrospective Headaches
• Nielsen Norman Group: Affinity Diagramming
• Retrium: The Five Phases of a Successful Retrospective
• Lean Enterprise Institute: 5 Whys
• Wikipedia: Ishikawa diagram
• MindTools: Sprint Retrospectives in Agile Project Management
• Diana Larsen: Circles and Soup

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