How to run a team retrospective that moves things forward

A team retrospective is a chance to look at how you worked together and decide what to improve. It can follow a sprint, a launch, a project milestone or a difficult week. The focus is the way the team works, rather than a status update on individual tasks.

Before the meeting, name the period you are reflecting on and invite the people who experienced it. A prompt such as “What helped or slowed us down during this launch?” gives everyone the same starting point. Keep the scope small enough to discuss in the time available.

Choose a facilitator to guide the conversation and keep an eye on time. They do not need to have the answers. Their job is to invite different perspectives, ask for examples and help the group choose a next step.

Use this as a starting point for a small team, then adjust it to your group. A larger team or a difficult topic may need more time. Protect the final action discussion even if you cannot cover every note.

• 5 minutes — Set the context. Agree the scope and remind people to discuss events and working practices without blaming individuals.
• 8 minutes — Reflect quietly. Ask what went well, what was difficult and what the team could try next.
• 7 minutes — Share and group. Read the notes, ask clarifying questions and bring related observations together.
• 15 minutes — Choose and discuss. Vote on useful topics, explore the examples behind them and look for a change within the team’s control.
• 10 minutes — Agree an experiment. Record an owner, a review date and what you hope to learn. Close by checking that everyone understands the next step.

Begin with quiet writing before opening the discussion. This gives people a moment to recall their own experience before the first speaker sets the direction. Ask for specific observations: “Reviews waited two days” is easier to explore than “Our process is broken.”

For a remote retrospective, send the board link and meeting details in advance. Explain how to add a note and offer another way to contribute if someone cannot use the board comfortably. Avoid making a fast internet connection or confident public speaking a condition of participation.

In Retro, a facilitator can enable private reflection and reveal the notes when the team is ready. This is a way to separate writing from discussion, not a promise of anonymity: shared notes retain their authors’ names. Explain that before people contribute.

Group related notes with the team, checking that the authors agree with the connection. Give each group a descriptive name. “Waiting for decisions” is more useful than “Communication” because it points to something you can examine.

Voting can help choose where to spend limited time, but the vote is an input to the conversation. A concern that affects only one person can still matter. Ask whether anything urgent or important needs attention before following the highest vote count.

For the chosen topic, ask what happened, what effect it had and what the team could influence next time. Park unrelated questions so they are recorded without taking over the discussion.

Choose a small experiment instead of a broad promise. “For the next week, add a reviewer when opening a pull request” gives the team something to try. “Communicate better” leaves everyone to interpret the action differently.

Give the experiment an owner and a review date. The owner helps it move forward; they are not responsible for fixing a whole team’s habits alone. Record what you expect to change and how you will decide whether it helped.

Open the next retrospective by reviewing that experiment. Keep it, adjust it or stop it based on what happened. That follow-up connects the conversation to everyday work and gives the next meeting a clear place to begin.