Have you ever witnessed a retrospective during which the team spent most of the time discussing issues instead of looking for ways to improve? Or a meeting when the number of concerns, threats and problems identified by the team was overwhelming? Both scenarios are frustrating right? They also inevitably lead to a situation where your team slowly loses its hope in their ability to change anything.
I found retros especially challenging during my last two projects. Both of them were quite big and the size of each team occasionally exceeded the recommended amount of people for a scrum team.
In order to handle these projects, I needed a retro technique that would allow me to gather ideas quickly, properly identify the most important concerns to discuss, and then spend most of the time on the actual problem-solving discussion.
In this article I’m going to walk you through my ideal retrospective step by step. As you’ll learn, it’s time efficient (between 60 and 90 minutes), properly balanced between problem identification and problem-solving, and results in a clear, accountable and deliverable to-do list in the end.
Stage 0 (during the sprint)
The team is asked to collect retro ideas during the entire sprint. It’s not so important how. They can use to-do lists, notebooks or stickies. The important thing is to gather ideas simultaneously with the sprint.
It’s going to take a while before your team accepts that practice. But, once you hear them saying “I have to write it down for retro” during daily meetings, or “I had this written down a week ago” during a retrospective — you’re on the right track.
Usually, I use common Scrum retrospective questions to stimulate the team (What worked well? What didn’t work? What could be improved?). It’s also vital to change these questions according to each project and its context.
Stage 1 (up to 30 minutes)
Understanding ideas and choosing the most important ones.
The team gathers after the sprint review (in my case usually the day after) for a retro. Scrum Master always starts by reviewing the progress of to-dos from the previous retrospective. It’s a bit like a status report designed to make a team feel responsible for their actions. If you don’t think it’s necessary now, you’ll understand in a second.
Each team member has a marker and a set of stickies. They have five minutes to move their ideas onto the stickies. It’s not necessary to write a detailed description, just a keyword is enough. However, remember to keep each idea on a separate sticky.
Team members can produce as many stickies as they want, but they should be aware that only five of them will be presented. Still, it’s better to collect more ideas during the sprint and bring them all to retro to decide on the spot which ones you’d like to choose for the board.
Once the stickies are ready, each team member is asked to present his/her ideas for 2 minutes. Keep in mind, this is not a moment to discuss the problems identified. People can ask questions to better understand the idea but they shouldn’t argue or disagree with the statement just yet.
A person stands in front of the team and passes the stickies to the Scrum Master while describing them. It’s good for a SM to briefly sum up these topics to make sure that the team is on the same page.
Scrum Master places the stickies onto the board, dividing them into three areas connected to retrospective questions. It may happen that you won’t know where a specific sticky should go — usually I end up placing them between two different categories. I also find it useful to create groups with the ‘unrelated’ sickies if they revolve around the same subject.
After this round (which usually takes 15 mins for a group of 9 people) Scrum Master identifies the most common topics. Usually, I circle them with a marker (example in the picture above) and talk through each group.
Time for voting. Each team member is allowed to put up to three dots (votes) on the board. He/she could vote for a whole topic group or a single sticky (see color dots in the picture above). He/she can place all three dots on one sticky or decide not to vote at all (although I’d discourage it).
Scrum Master identifies 3–4 most voted topics by counting the dots. Usually, big topic groups gather many points, however, it also happens that a stand-alone idea raised by one team member gets a massive amount of votes.
I do believe this technique is a great tool to efficiently find what’s important for the team to discuss.
Stage 2 (up to 30 minutes)
Gathering improvement ideas.
Scrum Master initiates an open discussion about each previously selected topic. It starts with a loose conversion to really dig into a problem.
Questions to ask during the discussion:
- Why is this happening?
- Why are we doing it?
- What was the cause of the issue?
By answering these questions, your team will have a clear understanding of each topic.
The discussion should slowly transform into an actual brain-storming session. Scrum Master should moderate the talk to search for improvement ideas and keep the team from complaining too much aka wasting time. When this happens, just ask them “OK OK, but what we could do about it?”.
It’s also good to support your team members in sharing as many wild ideas as possible. You can encourage them by giving your own crazy examples like “We could always solve the issue by ending the project if only we all agree that this is the best solution” or “If we are struggling with the lack of testing devices I will buy 10 of them on eBay using my credit card. We can’t wait anymore”.
Remember, as a Scrum Master you have to timebox each topic — 10 minutes each.
After brainstorming, you and your team go through all the wild ideas to search for realistic goals that can be accomplished by the next retrospective. You should end the meeting with a to-do list, a responsible person allocated to each task, description and a due date.
Keep in mind, these tasks should be achievable within a reasonable timeframe (preferably days and up to two sprints)!
All this should be either written on a board or displayed on a screen. I found it to resonate badly with the team to have my notes being written down on my laptop, not displayed for everyone else to see.
Stage 3 (offline)
Scrum Master prepares retro meeting notes, usually moving tasks from the whiteboard to the issue tracking system used by the team.
I tend to include as many people as possible in the to-do list. As we all know it’s the scrum team that’s responsible for the project and its routines, not the Scrum Master.
This guide was created based on the specific case, as all projects are unique. I don’t believe that you and your team should blindly follow it. I do believe, however, that there are 3 universal points you can take away with you:
- Gather ideas fast to quickly focus on the top 3 most important ones;
- Save a lot of time for a real problem-solving discussion;
- Produce a realistic and accountable to-do list.
This is a digital PM blog. I am not an architect nor a Plant Manager. Each time the word “project” is being used in this blog it refers to complex collaborative activities with minimal repeatability, where requirements are hard to specify and workload difficult to estimate. Many times it is more expensive to describe all requirements precisely than to deliver a draft of an expected solution.