Our thoughts on how to run good Retrospectives

by Sergio Gianazza, Founder

What are Retrospectives?

Retrospectives are sessions that Teams use to improve. We mean any improvement, which can be a technical improvement or an improvement in internal communication. There are lots of "conversations" about the retrospective cadence, but in the end, that is up to your Team.

This Blog Post will try to describe some tips and tricks on how to run effective retrospectives (100% from our perspective, so all of this is extremely biased). The end goal is to have something that guides Teams if they don’t know how to run retros.

Most of the things here come from the book Agile Retrospectives by Esther Derby and from our personal experience running retrospectives.

#1 Simple > Complex, or: use the simplest tool for the job.

When running a retro, use the tool that is simpler for the task. It can be a whiteboard if you’re in person. When you’re doing a retro with a remote Team, you can use any of the tools available (Retrium, Miro, Mural, or Free Form), just use the simplest tool for the job (even a Google doc - or drawing - can be the right tool).

#2 Guided > Chaotic, or: It is good for every retrospective to have a moderator

The moderator is responsible for keeping track of the time, switching between exercises, and even “Reading” the Team flow and deciding which type of session to run.

The moderator must be objective, which means that the moderator must not participate in the decision / ideas / voting during the retro (they are usually bias and might - unintentionally - guide the retro to get the output they want, and not the output the Team needs)

#3 Focus > Widespread, or: It is good for every retrospective to have a goal

The goal is what drives the retrospective, is what the Team will try to improve.

Not having a goal will lead to a Team trying to fix everything at the same time and not focusing on only one thing (which leads to less creative solutions).

Every person on the team will have a different opinion about what is the most important thing that the Team should fix now. Narrowing the goal to only one helps the Team bring the focus to only one topic.

💡Tips for setting the goal of the retrospective

  • The moderator can have a list of possible goals and start the retrospective session with a voting, the goal that has the most votes should be the one to use.
    • If there is a tie, the Team should vote again until there is a winner.
  • The moderator can suggest a goal, explaining to the Team why he is suggesting that particular one.
  • Examples of good goals are:
    • Find ways to improve our practices.
    • Discover what we were doing well.
    • Find ways to improve our responsiveness to customer support.
    • Rebuild damaged relationships with some part of the organization / customers.
    • Find ways to honor our commitments from retrospectives (useful when a Team commits to things then they are not doing)

#4 play > all work, or: Retrospectives should be divided into sections (with activities) that helps the Team get context, think of ideas to improve, propose goals and then commit to one of thems

The end goal of the moderator is to guide the Team through some phases, each phase will help the Team connect between them and with the goal of the retrospective. We like the phases proposed by Esther Derby, where each phase has a different goal, but all of them are interconnected.

The phases should be:

Set the Stage

During this phase we help people focus on the work at hand. Here we present the goal for the retrospective. Here the moderator should find an exercise that helps the Team express how they are feeling toward the retrospective to come.

Gather Data

The idea of this phase is to come up with a shared vision of what happened between the last retrospective and this one. Here we’re looking for hard data: events, metrics. But also we want to get feelings and emotions from the Team.

Again, this phase will help the Team get a shared understanding of what happened and why we are in the state we’re at now.

Generate Insight

Now is the time to ask “Why?” and begin thinking about what to do differently. The moderator should lead the Team to generate ideas to improve / fix / keep doing things.

Decide What to Do

At this point, the team has a list of potential experiments and improvements, now is the time to pick the top item (ideally one, no more than two).

Close the Retrospective

Do not let people dribble away! Use the last minutes of the retrospective to get a close to it. The moderator can (and should) use this time to run a small feedback session to find ways to improve the retrospective.


Each section should have a scheduled time, do not let one phase take more time than it should take or you will need to reduce the time for the next phase.

If you’re running a 1 hour retrospective, the ideal split should be something like:

  1. Set the stage: 5 minutes
  2. Gather Data: 20 minutes
  3. Generate Insight: 20 minutes
  4. Decide what to do: 10 minutes
  5. Close the retrospective: 5 minutes

Each phase should also have their own “activity”, as a moderator you should be ready to swap activities if one of them is not a perfect match for the Team energy. F.I: If the Team is feeling negative or with not much energy, do not use a brainstorming session in the “Generate Insight” phase, but if the Team is really energized you should use it!

There are tons of exercise to use (and you can even create some), I have a small Miro Board with scaffold activities than I can copy / paste to the Miro board of the retro, you can also get some ideas from the RetroMat or, if you’re feeling adventurous, you can try to adapt some of the Tasty Cupcakes exercises.

#5 specific > not specific, or: Commitments should be SMART

All commitments should follow the SMART rule, they should be:

  • Specific: The commitment should fix / improve / keep something specific.
  • Measurable: The Team should know when this commitment is fulfilled.
  • Attainable: Should be something the Team can accomplish in the next week / 15 days.
  • Relevant: Should be something that makes sense for the Team (and should be aligned with the retrospective’s goal)
  • Timely: Should have a moment in which this will be done

Example of a good commitments is:

  • Our goal is to do mob sessions at least three times a week. Sergio is going to schedule a 2 hour recurring session starting next monday.
    • This is specific: setting a recurring mob session to fulfill the goal of having mob session / pairing sessions.
    • This is measurable: We will know by next monday if Sergio did schedule the meetings or not.
    • This is attainable: Scheduling a meeting is something that can be done in less than a week.
    • This is relevant: This commitment is going to improve the team collaboration (which, we can assume was the goal of this retro).
    • This is “timely”: There is a specific date in which this will happen.

#6 less > more, or: do not commit to everything, pick the top commitments.

Most of the time, moderators (and even the Team) will be tempted to commit to multiple things, trying to improve as much as possible. Committing to multiple things might lead to failed commitments.

Keeping a short list of commitments helps the Team focus on the improvements they want to make, and prevents overflowing the Team with tasks. The problem with a long list of commitments is the Team will not have time to work on all of those improvements AND the work for the iteration, which usually leads to keeping a list of commitments that the Team will "eventually" work on (and guess what? they will never do).


As you can see, running a retrospective is not an easy job, it requires time and effort, we hope this guide help you running better, more fun and engaging retrospectives.

If you want to get notified when we release a new Blog Post, you can subscribe to our newsletter (We promise we won't spam you). Also, if you have any question you can write us to info@softwarepsychonaut.com

More articles

Stop stop using X and move to Y

Why you should not think always to move to the next cool technology

Read more

Your own, personal, HTTP Server

Some easy way to start a small HTTP Server to quickly test your HTML page

Read more

Tell us about your project