Scrum Retrospective Teardown — Best Practices and Tools
Everything you need to conduct a good Scrum Retrospective
Retrospective (from latin. retrospectare, “look back”) means to take a look back at events that already have taken place.
In Scrum, there a concept of a Retrospective meeting. It may seem like a useless ceremony, but in fact, it drastically improves the development process of an Agile team, especially if the team is distributed.
A Scrum Retrospective is a meeting held at the end of a Sprint to discuss what was done right and what can be improved. Many teams skip it. But don’t be like them — it’s like skipping a health check.
Scrum Retrospective provides an opportunity for a team to look back and inspect its productivity. As a result, the team comes up with a plan of improvements for a next Sprint.
A Retrospective meeting takes place after Sprint Review and before an upcoming Sprint Planning. Scrum Master makes sure that the team understands its purpose and holds a meeting on a regular basis.
This post is brought to you by Standuply — Digital Scrum Master for Slack. Want to put Scrum ceremonies on autopilot? Add Standuply to Slack today.
To run a good Scrum retrospective you need several ingredients combined. Here they are.
- The whole team. Agile methodology recommends gathering all the members including the product owners.
- A dedicated place for conducting a retrospective. Ideally, it should be a separate room.
- Drawing board or a flip chart.
- Markers with different colors.
- From a half an hour to two hours of spare time. It depends on the frequency of retrospectives and the size of the team.
- A host, ‘the person with a marker’.
- Optional, but recommended: snacks and drinks 🍷🧀
Before Scrum retrospective you can have recourse to some icebreakers, they will help you to cheer up the team.
To run a good retro, you need to decide who’s the host and then gather the whole team including product owners. It is not recommended for the leader to be such a host. Usually, it’s the Scrum Master’s role.
I recommend having retrospectives after every finished sprint. Spend at least 30 minutes for this purpose. It will make retro meetings more efficient and create a positive habit for the team.
Here’s the step-by-step guide on how to run efficiently retrospective meetings with your team.
Step #1 — Gather opinions.
Gather items the team liked and disliked about the past Sprint. Do not discuss them yet, make sure to write all of them down on a whiteboard.
First, ask the team about the things they like. These are some question samples that a host asks the team members.
- What did you like in the last iteration?
- What positive moments can you name?
- What would you like to write down under the ‘likes’ section?
The same questions can be applied to the section of what the team dislikes.
Step #2 — Count votes.
Run voting to define most popular issues for a discussion. Remember, your task is to continue doing what works and get rid of the rest.
The most important at this step is not to start discussing the items but just fixing them.
A voting can be run openly and anonymously. In the case of later the host collects the paper sheets with the numbers written on them. An open poll can has several variations to choose from.
- Regular voting, where each person adds as many votes to every item as she wants.
- Each person provides a weighted vote to each input (i.e., lifting fingers up).
- Vote numbers limitation. Everybody can vote only for some part of the list of inputs.
The host is counting votes and writing down a number against each input. The most popular inputs are allocated in each section. Usually, there are 3–4 of them. These are the most liked/disliked items.
The inputs from the ‘Likes’ section are fixed in the retrospective report for the team’s information.
The inputs from ‘dislikes’ have to be worked on more thoroughly. Now it’s time to discuss them.
Step #3 — Discussion.
At this step, a team is free to start a discussion. Talk about the main issues and find the ways to resolve them. It may take time to find the right solutions, formulate and assign tasks.
The whole team should decide what they want to:
- start doing in the next Sprint;
- stop doing;
- continue doing;
Every decision made during a discussion part should be fixed in the retrospective report and shared with all the team members.
At the very end of the retro, you can quickly discuss results from the previous ones. Team members in charge usually speak about what has been done. Sometimes you can correction previous tasks based on the new data and experience.
Step #4 — Meeting notes.
A common mistake is not to fix meeting notes and assigning tasks verbally. Don’t fall into this trap as you won’t be able to look back and track retro meetings’ efficiency over time.
Fix the results of the retrospective meeting in meeting minutes or in a task tracker adding relevant tasks. Then share the results with all participants.
Here’s one of the main issues with retrospective meetings. When you meet after two weeks of Sprint, no one can’t remember what was inefficient during that Sprint.
It sounds funny but true. Let me tell you the way to solve that problem via Slack.
You can use a Slack bot Standuply to ask your team members questions during the Sprint. This way by the end of the iteration the team will have all their inputs for a retrospective meeting.
Standuply can record retrospective feedback from the team members during the sprint and then send it directly to Scrum Master or PM via DM to be discussed on the “live” retrospective meeting at the end of an iteration.
Teams using Standuply set up the bot to ask retro questions once a week and then bring all the notes to the retrospective meeting. It saves their time and provide structure to their offline meetings.
Retrospective tools for the Web
If you don’t use Slack, but want to improve your Scrum retrospective meetings, here are some other great tools to try.
Retrium is one of the only tools designed specifically for retrospectives and it’s great. In a single click, it lets you run powerful retrospective techniques, like Mad Sad Glad and Start-Stop Continue. Each technique includes private brainstorming, dot voting, prioritized discussion, and more.
RetroTime is designed for agile retrospectives and creates a simple way for teams to collaborate and determine the actions items you should take after your retrospective meeting.
Fun Retrospectives provides the ways to make retro meetings more fun. Of course, you need to adjust these methods to make them work for your team. The point is, use different methods each time and you’ll get a lot of different feedback.
You can find more tools in the Distributed Retrospectives Wiki.
Running a retrospective meeting is not a rocket science. What I’ve said sounds quite simple and logical but very often it takes time for the teams to make retrospectives useful and effective.
Agile is about being consistent. It is demanding, but consistency makes it work. Once you feel the process works for your team, the goal is to make it as consistent as brushing your teeth each morning.
Remember, each time you fail in keeping consistency your competitors get an advantage of you and can’t wait to kick your butt. Don’t make such a present to them.
Be awesome!
By the way, check out my recent posts on team meetings and remote work:
