Sprint Retrospective Playbook

Overview

The Sprint Retrospective, (the Retro,) is where the Team review how they went in the previous Sprint with the express intent of defining something they will do differently that will help them to improve.

Sprint Retrospective occurs after Sprint Review so feedback and learning from the Sprint Review can be included in the conversation.

Sprint Retrospective occurs before Sprint Planning so the capacity required for the selected improvement action can be included in the Sprint Backlog.

It represents the 'inspect and adapt' cycle for the Team's processes and practices.

There are 5 steps in completing this Playbook

Preparation
Create a safe space and establish focus
Diverge to gather inputs
Converge to share context and allow insights to emerge
Define an improvement action or behaviour

Purpose

The purpose of the Sprint Retrospective is to:

Inspect how the last Sprint went with regards to people, relationships, process, and tools
Build a habit for continous improvement
Team bonding through sharing context
Improvement actions that uplift the Team's capability and performance
Reportable and measurable uplift of processes and practices
Identify impediments and constraints

Participants

All Team Members
Scrum Master
Product Owner

Difficulty

3 - Moderate

Duration

Timeboxed to 1-4 hours, (usually 1 hour per week of Sprint, so a 2 week Sprint would conclude with a 2 hour Sprint Retrospective.)

Materials

Team's Visual Management Board

Somewhere to capture inputs and record the results of the conversation

Meetings to cancel when you set up your Sprint Retrospective

PIR
Process or practices reviews
Checkpoints
Anyting else that is about improving how the Team operates, Sprint Retrospective enables them to do that for themselves

Preparation

When facilitating the Sprint Retrospective for a Team, you will want to help the Team to develop a shared understanding of each other's context and experience throughout the Sprint.

Be ready to bring forth the story of the Sprint, either by sharing the story yourself, or by eliciting it from the Team.

Mix it up occasionally by choosing a different Retro format.

WWW
- What worked well?
- What didn't work well?
- What can we improve?
Stop/Start/Continue
- What will we stop doing
- What will we start doing
- What will we continue doing
FLAP
- Future direction
- Lessons learned
- Accomplishments
- Problem areas
Hot air balloon
- What gives us lift?
- What weighs us down?
Sailboat
- What puts wind in our sails to help us go faster?
- What acts like an anchor and holds us back?
- What rocks are ahead that might damage us?

Be prepared with the details from the previous sprint:

Coaching logs – who did the Scrum Master or Coach interact with, what was the coaching focus.
What impediments emerged?
- How were they dealt with?
- When, how and by whom were they raised and resolved
Inspecting outputs
- Did we deliver everything we committed to?
- Was everything delivered to the right quality?
- Was everything delivered accepted?
Inspecting outcomes
- Did the delivered output create the desired outcome?
Inspectign metrics:
- Burn down charts
- Burn up chart
- Any other time or event metrics

If there were any difficulties in the previous Sprint that prevented the Team from achieving their Sprint Goal, you might prepare a focusing question for the Retro.

Prepare for divergent and convergent note taking and discussion

If you're facilitating in a room, bring lots of Post-it notes and prepare a whiteboard with the columns you need to capture and arrange input.

If you're facilitating in a virtual setting, prepare a Miro board or your favourite online retro tool, (Jira and Confluence work together nicely to create a nice Retro.)

Create safety and a establish focus

One thing that is absolutely essential in facilitating a Retro, is psychological safety, without it, people will only share what they know to be safe which might exclude the most important issues that happened in the Sprint.

We want to share the truth, warts and all, even if it is uncomfortable rather than focusing on the comforting lies that we share when we feel unsafe. Only when we have a sharing of the truth can we improve the most impactful things that are holding the Team back.

While you cannot necessarily overcome a culture in a Team that lacks safety, for example if one Team Member is bullying another Team Member, you can ensure that the way you facilitate is safe.

PRO TIP!

Start the Retro in a way that explicitely sets out some ground rules that support safety.

Highlight the Retrospective Prime Directive

"Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand."

What's said in the Retro, stays in the Retro

Make sure everyone knows that the conversation MUST remain confidential.

The Team will share the action they define, but the conversation is private.

Prime_Directve

Diverge to gather inputs

While a traditional brainstorming session is a fantastic way to generate a lot of creative ideas in a short time, it doesn't always allow the quietest voices to be heard and it suffers from anchoring bias where we react to the ideas that are called out, possibly forgetting the contribution we were intending to make.

For an effective Retro, we want to be sure all voices are heard equally and all contributions are collected.

To achieve that, we diverge and collect our inputs individually before coming together later to share and discuss those ideas.

If you're facilitating a co-located Retro with everyone in the room, then asking participants to collect their thoughts on Post-it notes is a fantastic way to gather individual inputs during the diverge step.

If you're facilitating a remote or hybrid Retro, then use a virtual tool like Miro or a virtual whiteboard. Make sure each participant has their own space to capture their ideas, so they are not influenced by the ideas others add.

By diverging and giving people time for individual thought, you ensure all ideas are captured as well and creating equal voice so even the quietest people have an opportunity to contribute.

PRO TIP!

Set a timebox to help participants avoid getting bogged down.

If you are planning a 2 hour Retro:

10 minutes for setting the scene
30 minutes for Diverge and capture inputs
60 minutes for converge and share context
20 minutes for determine actions

Converge to share context and allow insights to emerge

When you have collected the inputs with individual thinking, it's time to come together again and build a shared context.

Before diving into the discussion itself, arrange the items raised so that similar items are grouped together, this can help focus the conversation and makes it visible when multiple people raise similar topics.

Ask participants to share the items they noted and what those items mean to them. Ensure they know to stick to the issues at hand and not to make it personal, you mighht need to remind people of the Prime Directive.

Invite positive discussion but be careful that it doesn't result in people's contribution being challenged, we want to establish a shared context without making people feel that the items they raise need to meet with the approval of the team.

Allow each person to take their turn sharing the items they raised and inviting contribution from others who may have experienced something aligned to their item.

Define an improvement action or behaviour

When each team member has had the opportunity to share their experiences through the Sprint and discuss the items they have raised, it's time to work on defining what we will do differently next Sprint that will help us to improve.

Ask participants to vote on the items raised that offer the greatest opportunity for improvement.

Dot voting is a good technique, where each participant has a number of votes to cast that they can distribute however they see fit. If you decide 3 vites per person for example, a participant could put one vote each on 3 different items, or they could put all 3 votes on one item if they feel strongly that it is the greatest candidate for improvement.

When you tally up the votes it should be easy to determine the issue that the Team feel will help them to improve the most.

Performing a root cause analysis before jumping to the solution is a good idea as it helps to define a simpler solution to resolving the problem at it's cause. This will solve the problem in the long term instead of just putting a bandaid on the issue and having it return in the future. Ask participants, "Why does this problem happen?" or, "What happens to cause this issue?"

When you have agreed what the action or behaviour is that you will take on as a team to improve your performance, decide how you will measure whether it is working. An action that has a defined success metric is much more likely to have a positive impact and it also allows a conversation about whether the improvement action is actually working or not.

PRO TIP!

Defining an improvement action is only step 1.

Make sure you add it to your backlog and include it in your Sprint Planning so the capacity for doing it can be considered and it remains visible.