A scrum retrospective is a crucial meeting in your team’s calendar. It’s a chance to analyze the previous sprint and “create a plan for improvements to be enacted during the next sprint” (source: the Scrum Guide). If you want your team to perform better and your team members to feel better about their work, the retrospective is the meeting you should put much focus on.
Since retrospectives happen regularly (between every Sprint Review and Sprint Planning), you have plenty of opportunities to inspire your team members to share their ideas for improvements. The downside of retrospectives happening quite often is that they can easily change into routine gatherings that people want just to sit through and survive.
If your team has also been affected by the retrospective fatigue, or you don’t see tangible results of these meetings, you’ll find this blog post especially useful. We’ve collected a couple of ideas to refresh your agile retrospective ceremony and maximize the benefits for your team.
We’re not reinventing the wheel here. A scrum retrospective has an established structure that doesn’t need to be taken apart in order to make the meeting more productive. You can, however, change the way you usually go about certain parts of the retrospective:
Collecting notes from different members of the team is an essential part of a scrum retrospective. The chances are that you’ve been using the same formula to gather feedback for a while. It could be a table with start, stop, continue columns, or the sailboat metaphor. They might have worked well at the beginning but, with time, got a little stale.
You can freshen things up by essentially doing the same thing, but slightly changing the form of this exercise. It will feel fresh and might inspire your team to come up with new items:
The goal of this stage of the retrospective is to dig deeper into the points brought up by your team. You want to know why did things happen this way? Before you dive deeper into selected items, you need to pick which ones require the most attention. This decision is often made by voting. You can, however, find different ways of deciding on the subject for the rest of your agile retrospective.
One of the ideas for filtering your sticky notes (or virtual notes if you’re running a scrum retrospective for remote employees) is to place them on the likelihood vs. impact chart. Draw a chart on which the x-axis represents the impact of a given action (if completed successfully), and the y-axis represents the likelihood of that action happening in the first place. Then, ask your group to place all of the items in appropriate spots on the chart. Once they’re mapped, you can pick the priority items (high impact, high likelihood) and the ones that likely don’t need to be discussed (low impact, low likelihood). This exercise was described by Fun Retrospectives.
The challenge of creating action items is to make them stick. If you noticed that action items from previous retrospectives were quickly abandoned, you should alter the way you formulate them.
Think about the SMART framework. Your action items (and the goals they’re supporting) should be:
Make sure that your retrospective’s participants would be able to answer the following questions about their action items:
What you can also do about these action items is to increase their visibility. If possible, display them on sticky notes, or as tickets in your project management software. Continuous action items (e.g., “Update your timesheets after each day”) can be facilitated with automatic reminders on Slack (or another tool you use for communication).
The following activities can become a part of your next agile retrospective. You don’t have to introduce all of them, but give at least one or two a try.
Retrospectives can easily turn into gloomy complain-fests. You might think that it’s not a bad thing: it’s an occasion to talk about the bad stuff as well. That’s true, but the meeting should result in a set of action items that will significantly improve your team’s processes. If it’s just an hour (or three hours) of complaining, the improvement is not likely to happen.
Yet another vital element of a successful retrospective is to make sure that the meeting is blameless. Sure, people are encouraged to speak their minds, but it doesn’t mean that they should point fingers. After all, the goal is to come up with constructive improvement ideas. This is not always easy to achieve, especially when the scrum retrospective is organized after an unpleasant incident during the sprint (software outage or team conflict).
How do you make sure that your team keeps these rules in mind? You can reiterate them as you start the retrospective, or you can use visual reminders: posters or sketchnotes that remind team members about the nature of this meeting.
Perhaps your team will be inspired by the words of the 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.
Norm Kerth, Project Retrospectives: A Handbook for Team Review
Checking how your team feels is useful for the meeting facilitator, but it’s also an excellent ice breaker at the beginning of the agile retrospective.
Use a flipchart, a whiteboard, or sticky notes to represent people’s moods visually. Ask them to display their feelings with emoji or make a scale on which they can place themselves. It will help you to read the room during the retrospective. If you collect this kind of data regularly, you can uncover interesting patterns.
If you’re the person that always leads retrospectives, things may get a little repetitive for the participants. One of the retrospective ideas that teams find effective is to ask different people to facilitate at least a part of the meeting. It allows other people to get involved, dig a little deeper into the theory behind retrospectives. Your new facilitator might come up with ideas for in-meeting exercises that invigorate the whole team.
As a Project Manager or a team leader, you have access to reports filled with valuable insights into your team’s performance. It is a good idea to share them with your retrospective participants. They will learn important facts, and you can base the whole discussion on both: qualitative feedback and quantitative data.
What kind of data can you use?
We hope that this guide provides you with retrospective ideas that can work for your project. Whichever ones you choose, remember that in order to get your team on board with new initiatives, it’s best to give them insights into the goals of these actions. When they know why you’re doing it, they’ll be more likely to follow through and perhaps even contribute to your retrospective toolset with their own ideas.
As a company or team leader, you're undoubtedly aware of the effect KPIs may have on your team's morale and performance. Carefully selected performance indicators will help everyone on your team see if they're on the right...
Whether you're working at a software company or a creative agency, you probably know very well that projects don't end when someone pushes the final commit to the code base or when the client replies with "looks...
As a leader, you likely want your team to feel happy at work. Simultaneously, as a businessperson, you pay attention to your company's bottom line and want to keep it profitable. Fortunately, these two goals align. Studies...