Running Effective Retrospectives: Structure, Safety and Action

A retrospective is a regular meeting where a team looks back at how it has been working and decides what to change. It is one of the simplest agile practices and one of the easiest to get wrong. Done well, it is the engine of continuous improvement. Done badly, it becomes a complaint session that produces the same action items every few weeks.

The idea is built into agile thinking. One of the principles behind the Manifesto for Agile Software Development reads: "At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly." In Scrum, the Sprint Retrospective is a formal event whose purpose, according to the Scrum Guide, "is to plan ways to increase quality and effectiveness."

This guide covers a proven structure for retrospectives, a few formats to keep them fresh, how to build the safety people need to speak honestly, and how to turn good conversations into real change.

The Five-Phase Structure

The most widely used structure comes from Esther Derby and Diana Larsen's book "Agile Retrospectives: Making Good Teams Great," first published in 2006. A second edition, written with David Horowitz, was published in 2024. Both describe five phases.

1. Set the stage. Welcome people, restate the purpose and timebox, and get everyone to speak briefly early on, for example with a one-word check-in. Many facilitators find that people who speak early are more likely to keep contributing.
2. Gather data. Build a shared picture of what actually happened: events, metrics, feelings and decisions. Memories differ, so this phase grounds the discussion in facts rather than impressions.
3. Generate insights. Ask why things happened. Look for patterns and root causes instead of jumping straight to fixes.
4. Decide what to do. Choose a small number of concrete experiments or changes the team will commit to.
5. Close the retrospective. Summarize decisions, thank people, and briefly reflect on the retrospective itself so the next one improves.

The most common mistake is collapsing phases two through four into a single question, "What should we change?" Teams then fix symptoms they have not understood. Giving each phase its own time produces better actions.

Timing and Rhythm

The Scrum Guide timeboxes the Sprint Retrospective "to a maximum of three hours for a one-month Sprint," noting that "for shorter Sprints, the event is usually shorter." Many teams on two-week cycles find that 60 to 90 minutes is enough. Teams that do not use Scrum still benefit from a regular, scheduled retrospective rather than holding one only when something goes wrong.

As a rough split for a 60-minute session, you might spend 5 minutes setting the stage, 15 gathering data, 20 generating insights, 15 deciding what to do and 5 closing. Adjust to fit your team.

Formats That Keep It Fresh

Running the same activity every time leads to the same answers. Rotating formats helps people notice different things. Some widely used options are listed below.

• Start, stop, continue: what should we begin doing, stop doing and keep doing?
• Mad, sad, glad: a quick way to surface feelings about the period, useful when morale is a concern.
• Timeline: the team plots key events across the sprint, then marks highs and lows. This works well for the gather data phase.
• Sailboat: the team draws a boat, with wind representing what pushed it forward, anchors representing what held it back, and rocks representing risks ahead.
• Five whys: for a single important problem, repeatedly ask why it happened to find a deeper cause.

Each format fits a particular phase better than others. A timeline is a data-gathering tool, for instance, while five whys belongs in generating insights. Mix formats across phases rather than letting one activity fill the whole meeting.

Building Psychological Safety

Retrospectives only work if people say what they really think. The term psychological safety was popularized in a team setting by researcher Amy Edmondson, whose 1999 paper "Psychological Safety and Learning Behavior in Work Teams" appeared in Administrative Science Quarterly. Broadly, it describes a shared belief that it is safe to take interpersonal risks, such as admitting a mistake or questioning a decision, without being embarrassed or punished.

Many facilitators open with the Retrospective Prime Directive, written by Norm Kerth in his book "Project Retrospectives": "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." Reading it aloud signals that the goal is learning, not blame.

Other practical steps help too. Agree that what is said in the room stays in the room unless the team decides otherwise. Think carefully about whether managers attend; their presence can quiet people even when they mean well. Use silent writing before discussion so quieter members contribute. And when someone raises a hard truth, thank them, because how the group reacts the first time shapes whether anyone does it again.

Turning Insights Into Action

The value of a retrospective lies in what changes afterward. A few habits make follow-through far more likely.

• Pick one to three actions, not ten. A team that finishes one improvement each sprint will outpace a team that starts many.
• Make each action specific and testable, for example "Pair on every story touching the payment module for the next two sprints" rather than "Improve code quality."
• Give each action an owner who will make sure it happens, even if the whole team does the work.
• Put actions where the work lives. The Scrum Guide notes that the most impactful improvements "may even be added to the Sprint Backlog for the next Sprint."
• Start the next retrospective by reviewing last time's actions. Did they happen? Did they help?

Treat actions as experiments. If a change does not help, that is useful information, and the team can try something else.

Key takeaways

• Retrospectives exist to help a team inspect how it works and decide on concrete improvements.
• Derby and Larsen's five phases, set the stage, gather data, generate insights, decide what to do and close, keep teams from jumping to shallow fixes.
• Rotating formats and matching them to phases keeps conversations fresh and useful.
• Psychological safety is a precondition for honest discussion, and facilitators can actively build it.
• Choose a few specific, owned actions and review them at the start of the next retrospective.

Sources

• Esther Derby, Diana Larsen and David Horowitz, Agile Retrospectives, Second Edition (Pragmatic Bookshelf)
• Esther Derby and Diana Larsen, Agile Retrospectives: Making Good Teams Great (Pragmatic Bookshelf, 2006)
• The 2020 Scrum Guide
• Manifesto for Agile Software Development, Principles
• Retrospective Wiki, The Prime Directive