5 whiteboard templates

5 whiteboard templates for brainstorming action items in retrospectives

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.

Possible experiments:

  • 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:

Share this article in your network

Echometer is the smartest way to improve the team's delivery for busy team leads

The tool combines agile health checks, action item tracking and interactive, psychology-based retrospectives on autopilot.

Articles you may also be interested in

Echometer Newsletter

Don't miss updates on Echometer & get inspiration for agile working