Besides the fun and team building factor in a retrospective, the main purpose is to brainstorm and record meaningful action items. Whiteboard templates can be of great help here. In this article we introduce you to 5 essential whiteboard templates and explain how you can use them in different examples.
Retro Whiteboard Template #1: The “5x Why” Method
When to use the "5x why" in a retrospective
Before brainstorming actions in a retrospective, make sure the problem is adequately understood. Team members often have different perspectives on a problem. Sharing these perspectives helps develop a common understanding, which increases the effectiveness of interventions. The "5x Why" whiteboard template makes it possible to structure this process. It can easily be used together with Retrospective Template and complements it perfectly.
This is how the "5x why" method works
You start with the problem what you found during the “Gather data” phase of the retrospective and ask why the problem exists. The answer to this "why?" is noted accordingly in the template. Then it goes one level lower and you question the answer to the "Why?" again. This chain of “why” questions brings you closer to the actual core cause and along the way you can discover various alternative solutions.
After saying the "why?" has repeated up to 5 times, the team can brainstorm which “why” offers a good solution.
Practical example of the "5x why" in a retro
A very nice example for the creation of new perspectives through the "5x why" model are the high cleaning costs of the Washington Monument:
Problem: The cleaning costs of the Washington Monument are increasing enormously.
Why 1: Why are cleaning costs increasing? → Because there is so much bird droppings.
Why 2: Why is there so much bird droppings? → Because the monument attracts so many birds.
Why 3: Why does the monument attract so many birds? → Because there are so many insects there.
Why 4: Why are there so many insects on the monument? → Because it is illuminated for many hours in the evening.
Why 5: Why is the monument illuminated? → Because then it is more attractive for tourists.
Possible solutions after this root cause research:
- Less lighting for the monument
- Use lighting that will attract fewer insects
Retro Whiteboard Template #2: The Fishbone Diagram (Ishikawa)
When to use the fishbone diagram in a retrospective
Similar to the “5x why”, this whiteboard template is about researching the root causes. In contrast to the “5x why”, the aim here is to subdivide the core causes into different categories in order to create the broadest possible perspective.
This is how the fishbone diagram works
The problem to be treated is the fish's head. The first step is to define categories in which one suspects the core causes. Here you can choose from different standards , or brainstorm categories with your team.
Once the categories are set, each team member can brainstorm causes within this category and present them to the group. On the basis of the core causes developed, you can then decide as a team which starting points you want to use for measures.
Practical example of the herringbone diagram in a retro
Let's take a look at the herringbone diagram using the example of train delays:
Problem: 50% of the long-distance trains in Germany are more than 60 minutes late.
Brainstorm the categories for core causes:
- Route planning
- Rail network
- Weather influences
- Train itself
- Railway station & tracks
- Transfers & connecting trains
Based on the categories, you can now brainstorm which ones specific core causes hide themselves here. Examples could be:
- Route planning
- Too tight timing of trains on a route
- Too few options for alternative routes
- Approval processes for the approval of alternative routes are too long
- Rail network
- Backlog during maintenance work
- Failures in the power supply of a certain series
Based on the collected reasons, you can now evaluate which measures can be taken as a team.
Retro whiteboard template #3: The impact-effort-matrix
When to use the impact-effort-matrix in a retrospective
It often happens in retrospectives that there are many possible measures directly in the room. Then it is important to carefully consider which ideas for measures are the most promising. The impact-effort-matrix is ideal for such situations.
This is how the impact-effort-matrix works
The matrix describes the “effort” on the horizontal X-axis. The further to the right you place a topic, the higher the expected effort. The vertical Y-axis in turn describes the presumed impact that the action item would have. The following categories for measures arise from the resulting quadrants:
- Fill-ins (bottom left): Measures that are easy to implement, but that do not have a major impact
- Quick wins (top left): Easy to implement measures with a big impact
- Major Projects (top right): Complex measures with a major impact
- Thankless tasks (bottom right): Complex measures with a low impact
The following tends to apply: the further a measure is on the top left, the better. The exact placement of the proposed measures should be discussed together in the team.
Practical example of the impact-effort-matrix in a retro
Illustrated by the example “Feedback for support tickets is too slow”, measures from the quadrants in the influence-effort matrix could each read as follows:
Fill-ins (bottom left):
- Answer support tickets with an automatic confirmation of receipt (is simple, but is probably not satisfactory for the customer as the sole change)
Quick wins (top left):
- Assignment of the role of a “first responder” in order to avoid the diffusion of responsibility (if the diffusion of responsibility is a core cause of the long response times, this measure can be very effective)
Major Projects (top right):
- Set up an artificial intelligence that automatically processes up to 80% of the support requests (is probably a large project, but if it is successful it can also offer a corresponding sustainable added value)
Thankless tasks (bottom right):
- Set up a new process map for support inquiries (assuming the process map is out of date, but is hardly in use anyway and an update would therefore probably not have a major impact)
Retro whiteboard template #4: "Circles of Influence"
When to use the circles of influence in a retrospective
Many of the issues raised in a retrospective will be of a cross-team nature. This means that not all solutions are within the team's sphere of influence. The model of the circles of influence offers a good approach to clarify which initiatives can still be initiated at the individual or team level.
This is how the circles of influence work
After defining the problem, you start with the first phase of brainstorming. The first thing here is what each team member can do individually to solve the problem, or at least to mitigate the negative effects. You collect the same for team and organization levels.
The aim is to find out what you can change as a team in order to adapt as well as possible to the organizational framework. For the solution approaches outside of the team, it is again important to brainstorm which changes in the organization could be stimulated. Addressing problems related to the organizational framework outside of the team can also be a valuable measure.
Practical example of circles of influence in a retro
Let us illustrate the scope model using the example of the problem “product milestones are not met”:
What can everyone do for themselves?
- Actively question which preconditions must be present for your own contribution (in order to recognize delays due to external factors in advance).
- Actively share in the team how much uncertainty there is still in the implementation of topics (in order to make transparency early on that work packages cannot yet be precisely estimated).
What can we do as a team?
- Seek active exchange with other product teams in order to identify interface problems earlier
What changes in the organization can we encourage?
- Suggest 1 week “cool-down” period between sprints
- Propose the introduction of a better documentation logic for requirements and dependencies
Retro whiteboard template #5: Hypothesis & experiment
When to use the experiment template in a retrospective
In retrospectives one tends to plan action items too ambitiously. When implementing these major measures, day-to-day business then gets in the way and the implementation of the measure comes to a standstill until it is ignored. If this happens to you, the “experiment” template could help you to make measures smaller and to increase the speed and likelihood of implementation.
This is how the experiment template works
After defining the problem, it is a matter of describing a target state. It is important to understand what exactly changes in the target state and why that is so important. The next step is to brainstorm hypotheses as to why this target state has not yet occurred and which hurdles you have to overcome in order to achieve it.
Now it is a matter of proving these hypotheses through the smallest possible experiments. The target state does not necessarily have to be reached. Instead, the focus is on validating the hypothesis. The template helps the team to think in small steps.
Practical example of the experiment template in a retro
In practice, the example of working with experiments could look like this:
Problem: The product vision raises more questions for us than it answers.
Target state: The product vision gives us orientation and security to make our daily decisions in the team independently and to require less coordination with the product owner.
Hypothesis: We don't talk enough about the specific roadmap for how we want to achieve the product vision.
- Add a new field in Epics, in which Product Owner briefly explains the strategic importance and perspective.
- Conduct a workshop on the product vision and roadmap with the product owner
As indicated, the possible experiments from the brainstorming should each be small, easy-to-implement measures. These experiments will not necessarily solve the problem holistically. Therefore, one should actively take up the results and experiences from the experiments again in future retrospectives in order to decide on the basis of the new learnings (hypothesis confirmed or rejected?) Whether follow-up measures are required and, if so, which measures would be promising.
Use whiteboard templates in retrospectives
Having a few templates for brainstorming action items is not enough on its own. You also have to evaluate which template is suitable with which method for each situation. Hopefully the examples will help make this easier to assess.
💡 Tip for Echometer users
During the retro you can simply choose from the suggested whiteboard templates for each topic on the retro canvas, it doesn't matter which retrospective template you use. If you have created your own whiteboard templates, these are also available here: