Scrum for Beginners 3-5-3 Part 6: Sprint Retrospective Basics and 3 Pro Patterns

Hello! This is Part 6 of a series on scrum using the 3-5-3 framework (3 roles, 5 events, and 3 outputs) where we use the Scrum Guide as a base for our learning.

In this article we will cover:

• What is the sprint retrospective?
• Who joins the sprint retrospective? 🌸
• 3 sprint retrospective pro patterns 🌸

Click the emoji to jump to each section in the article.

What is the Sprint Retrospective?

The sprint retrospective is one of 5 scrum events as detailed in the Scrum Guide.

As a tip, if you want to know basic information about scrum, the Scrum Guide is a fantastic resource.

The Scrum Guide says:

The Scrum Team inspects how the last Sprint went with regards to individuals, interactions, processes, tools, and their Definition of Done.

...The Scrum Team identifies the most helpful changes to improve its effectiveness.

The Sprint Retrospective concludes the Sprint....

From this we can understand that the sprint retrospective is an event used to help the scrum team inspect and adapt their way of working to improve sprint to sprint.

Here are just some examples of valuable conversations that can come out of a sprint retrospective:

• Sprint goal had too many parts and we couldn't deliver everything
• People were absent so we had less capacity than expected
• A dependency outside the team slowed us down
• Unexpected bug meant we couldn't focus on implementing
• The implementation was harder than we anticipated

It's important to remember that within scrum, continuous improvement is crucial and part of our job and responsibility. For this reason, the sprint retrospective is dedicated time for reflecting and learning and teams should always bias in favor of holding the retrospective.

Who joins the Sprint Retrospective?

If we first refer to the Scrum Guide we can easily see who are the main attendees required for the retrospective:

The Scrum Team inspects how the last Sprint went with regards to individuals, interactions, processes, tools, and their Definition of Done. Inspected elements often vary with the domain of work. Assumptions that led them astray are identified and their origins explored. The Scrum Team discusses what went well during the Sprint, what problems it encountered, and how those problems were (or were not) solved.

 The Scrum Team identifies the most helpful changes to improve its effectiveness. The most impactful improvements are addressed as soon as possible. They may even be added to the Sprint Backlog for the next Sprint.

Let's quickly re-confirm who is implied when we say "the scrum team":

 -The Developers
 -The Product Owner
 -The Scrum Master

These are the only required participants for the retrospective and many scrum practitioners would argue that they should be the ONLY participants.

Because the retrospective is a time for reflecting on both the good and bad of the sprint, there are a few special conditions required:

• The retrospective must be a safe place to discuss sensitive topics
• The people who actually did the work should lead the discussion on how to improve
• Too many opinions outside the team can put pressure on them to conform which reduces team autonomy

For these reasons it is often advised to restrict the sprint retrospective to the scrum team. Sometimes other roles who worked closely with the scrum team during the sprint will also join the team retrospective.

3 Sprint Retrospective pro patterns for any team

Here are 3 quick pro patterns for more productive sprint retrospectives:

1. Gather ideas/topics beforehand
Where possible, whoever is facilitating the retro should have an idea of what the team might want to discuss.

This can be achieved in any number of ways:
 -Looking at past retro topics
 -Pulling from the sprint review or other big events where important topics are shared
 -Directly asking participants ahead of time if they have any topics they want to prioritize
 -Looking at the team impediment list

While having an idea is important, I want to note that the final decision on the topic of the retro belongs to the scrum team, not the facilitator. As always, open communication is necessary.

2. Scrum the scrum: retro the retro
The retrospective is the most important time for teams to inspect and adapt. If the value of the retro is not being felt, do a retro on the retro. Find the gaps and make the necessary changes to make it worth doing. A retro that doesn't benefit anyone is a waste of time and energy.

My advice is to always start with the outcome in mind: what do we want to get out of this retro?

3. Switch up the retrospective format
According to the Scrum Guide these are the important topics to be covered in a retrospective:

what went well during the Sprint
 what problems it encountered
 how those problems were (or were not) solved.

As always, the how is not dictated in the Scrum Guide because what works for one team will not necessarily work for another.

If you find your retrospectives getting stale or crucial information going undiscussed, changing your retrospective format can be an effective way to address the gap.

Retrospective formats can differ greatly from one another in many ways:

 -remote vs in-person
 -deciding topic beforehand vs deciding topic at the time of the retro
 -themes invoke different ways of thinking (focus on fun vs learning vs past vs future etc)
- timeframe (long term vs short-term)
 -outcome focused vs output focused
 -simple vs complicated topics

The same retrospective format may not work every time so it's important to strike a balance between what you hope to achieve and how you can achieve it with various retrospective formats.

I hope this helps clear up some basic information about the sprint retrospective and gives you some inspiration for how you can make your sprint retrospective more effective.