{"id":1195,"date":"2025-04-24T12:17:54","date_gmt":"2025-04-24T10:17:54","guid":{"rendered":"https:\/\/retromat.org\/blog\/?p=1195"},"modified":"2026-02-19T18:38:21","modified_gmt":"2026-02-19T17:38:21","slug":"11-why-do-we-do-retrospectives","status":"publish","type":"post","link":"https:\/\/retromat.org\/blog\/11-why-do-we-do-retrospectives\/","title":{"rendered":"11. Why do we do retrospectives?"},"content":{"rendered":"\n

[This post is part of Corinna’s Guide to Facilitating Retrospectives<\/a>]<\/p>\n\n\n\n

Hi friend!<\/p>\n\n\n\n

This is the first of three emails on follow-up<\/strong>. I\u2019d like to start by taking a step back and inspecting our reasons for doing retrospectives.<\/p>\n\n\n\n

Spoiler Alert: I’m not doing retros because the Scrum Guide says so.<\/p>\n\n\n\n

But why do we do them? Why invest our time to prepare and then everyone’s time when we all meet. What do we hope to gain for the time invested?<\/strong><\/p>\n\n\n\n

I invite you to think about that for 2 minutes. Close your eyes. Why do you run retrospectives?<\/strong><\/p>\n\n\n\n

[Two minutes later]<\/p>\n\n\n\n

Did you really take the 2 minutes though?? <\/p>\n\n\n\n

If not, here’s another chance to press pause and think.<\/strong><\/p>\n\n\n\n

…<\/p>\n\n\n\n

You thought about it? Great! What are your<\/strong> reasons?<\/p>\n\n\n\n

To me, there are two main goals in retrospectives:<\/p>\n\n\n\n

Shared Understanding<\/strong> and Change<\/strong><\/p>\n\n\n\n

Everybody sees the world differently. The retrospective is an opportunity to realize that there are many different interpretations and reactions to any given event. I want to make sure that everyone\u2019s voice is heard.<\/p>\n\n\n\n

Sometimes a retrospective does not result in any experiments. That is okay if it is an exception and the team members learned something about each other and how they tick. The shared understanding<\/strong> will then \u2013 hopefully \u2013 result in change even without concrete action items.<\/p>\n\n\n\n

But usually you want the team to explicitly try something new as the result of the retrospective \u2013 an experiment<\/strong>. Obviously, you’d love for the experiment to improve things, but they won\u2019t always do that and there’s no way to know in advance. The team has to try things out to see if they are an improvement or not.<\/p>\n\n\n\n

Aim for small experiments. They have a higher chance of actually being implemented. If an experiment works: Great! If it doesn\u2019t, you haven\u2019t invested much and can try something else. Rinse and repeat for continuous improvement.<\/p>\n\n\n\n

It\u2019s also better to limit yourselves to a few experiments. If you\u2019ve got lots of experiments, chances are very high that none of them will be carried out. If you\u2019ve only got 1-3, they have a better chance of actually being implemented.<\/p>\n\n\n\n

Experiments come in two flavors: Action Items (AIs) and Rule Changes<\/strong>.<\/p>\n\n\n\n

An Action Item<\/strong> is a concrete action that someone will do: <\/p>\n\n\n\n