Design agile retrospectives effectively and creatively
Design agile retrospectives effectively and creatively

Design agile retrospectives effectively and creatively

Almost everyone knows what agile retrospectives are and how they basically work. But how exactly do I plan them? What tools and resources can I use? We give you interesting insights and important support.

How do I plan an agile retrospective as effectively as possible?


Basically, there is a recommended process model – as there is for facilitation and workshops in general. This looks as follows:


  1. Create a mood
    As the name suggests, the first thing to do here is to “arrive”, a “warm-up” of the participants and/or an overview of the mood in the team. In the first retrospective, this step can be setting up rules for the appointment e.g. close all apps, let each other speak out or even the VEGAS rule: what is said in the retrospective remains under lock and key.
  2. Gather information
    This is often done by looking back and identifying what went well and what didn’t. There are various methods for this, e.g. “Mad, Sad, Glad” or “the 4 L’s”. The important thing is: we only discuss events and perceptions, not their causes or even solutions to them.
  3. Developing insights
    In this phase, we explore why something happened. This is important so that symptoms are not identified and fixed, but the actual cause is questioned.
  4. Decide what to do
    This phase involves making decisions about specific actions to be implemented in the near future – the sooner the better. The focus is not on mass, but on the quality of the measures. The phase is important because these changes are the goal of a retrospective. The appointment becomes really effective when not only measures but also hypotheses are derived. Ex: Problem: Code quality has deteriorated since the change in personnel. Action: Conduct code reviews with at least two reviewers. Hypothesis: If we conduct code reviews (at least 2 reviewers), then our code conventions can be met. The measure is then not finished after the implementation, but only if the fulfillment of this also confirms the hypothesis. If it does not, the next retrospective will work on a new measure.
  5. Conclusion
    Finally, the results of the retrospective are summarized and usually closed with feedback from the team. This is not only feedback for the facilitator, but also wishes, ideas, praise and criticism from the team for the team.


Each of these phases should be given a timebox – i.e. a maximum duration – at the planning stage. This allows the moderator to control the retrospective efficiently.


What tools and aids can I use virtually?


As is so often the case, there is a wide range of tools available here that more or less provide a structure for the retrospective. Classic retrospective tools provide a framework based on the five steps or focus on card queries and discussion. These tools are suitable for any novice facilitator and/or teams looking for a bit more structure but little variety and freedom. These include agile meeting tools such as Parabol, Retrium and, among others. More creativity and freedom in retro design is allowed by virtual whiteboards such as Conceptboard, Mural or Miro, among others.


Are there best practices?


In any case, there are “practices”, but whether they are really suitable for your team should be checked in advance. The Retromat – with suggestions and processes for (agile) retrospectives is highly recommended here.


There you will find a variety of methods to vary for each phase.


How do I find the most suitable method?


A bit of intuition is required here. Of course, the practices from Retromat and Co. help – but how do I combine the methods? On the one hand, the selection is based on the experiences in the last sprint. If a dominant theme is known, e.g. a conspicuous number of bugs, unsuccessful vacation handovers, long-awaited releases or team conflicts, then the retro should be allowed to give the theme a lot of space. Lightweight methods with space for descriptions, discussions, and – especially in the case of issues that need improvement – with a focus on root cause analysis are a good fit. All steps should be focused on this and not raise “side issues.”


As always, however, even if the facilitator may have discovered an essential “elephant in the room,” the team should be allowed to decide what is important to them, for example, via a show of hands or dot voting. If there is no topic in the room, the methods can focus more on topic and idea collection. Not only the last sprint has to be considered, but also longer periods of time. Fundamental things such as team rules or Agile values can also be considered: How well are our actions aligned with them? Where can we still improve?


A facilitator can also observe whether the team is better at talking about feelings or situations in the current situation and select methods accordingly. Some phrases like “Mad” / “Sad”, “bad” and “Fail” team members don’t like to hear, then softer or positive phrases can help (e.g. “Repeat and avoid” or “What does the perfect sprint look like”?).


In general, not only negative topics should be addressed in the retrospective, but enough space should be left for thanks, praise and success stories. One can also learn from successes – especially if they have been achieved via experiments.


How can I escape the retro routine?


If the team is more “playful” it needs creative methods. Retrospectives can be structured completely according to a motto, for example. The seasons, world days, events and holidays (e.g., carnival) are suitable themes. Each method should contain metaphors for the chosen theme. Let’s take the topic of carnival as an example – the teams can be asked, for example, which three things from the last sprint fit into the suitcase for the next one, or which costume – in relation to the last sprint – suits them best at carnival.


Or how about a “movie retro”: For this, the project team suggests a movie title that fits the current situation (for example, “Lara Croft: Pandorra’s Box” for a tricky bug) In the appointment, they then build on the movie plots. What is important in all creativity is that everyone in the team knows the metaphors and terms used. Create a kind of “legend” at the beginning.


Despite all creativity, do not forget here: Actions should be documented so that they become binding.




Retrospectives are as different as the teams and facilitators. At the end of a successful retrospective there are not necessarily many, but concrete measures – better: verifiable hypotheses, which make the team performance a little bit better.


For novice facilitators, “listed” methods are recommended for orientation, such as The best retrospective for beginners – All About Retrospectives.


Or a guided retrospective tool with a (limited) range of methods and a predefined structure. For more experienced facilitators, however, a whiteboard offers more necessary freedom for design.

Learn more about Agile Retrospectives!

Our team of experts for Agile project management will be happy to help you.

Michael Henninger, Project Management and Agile
Michael Henninger
Project Management and Agile