Taking the scrum retrospective to the next level | David Tzemach

The sprint retrospective meeting is one of the most important meetings in the scrum framework and should therefore be treated responsibly. However, planning and running an effective scrum retrospective is much easier said than done. Over the years, I’ve learned that there are some basic tips that can help increase the effectiveness of these meetings.

A few words about retrospectives

Retrospectives are important because they allow the team to concentrate both on the things that are keeping them from fulfilling their full potential in the agile environment but also to share the things that are working for them and that they want to preserve. During the meeting, the team has a safe space to discuss problems. But that is not all: the meeting also allows the team to feel empowered and share their achievements, celebrate successes and increase their morale.

So what can go wrong?

It is easy to understand why retrospectives are important as (what I love to call) the “engine” of improvement. However, there is a huge gap between using a preliminarily written script and actually having a retrospective. It can work maybe once or twice, but it usually starts to negatively impact the team to the point where they start treating the retrospective like another meeting that they are forced to participate in because of its part of the scrum framework. Another crucial issue is impediments that are not handled and monitored by the scrum master. Think about a team that is fully excited to share their problems in the retro meeting, but one week later, the scrum master presents the impediment board with the exact same problems without any real change. How do you think it will influence the team’s willingness to share their thoughts? Why would they share them if they know that nothing will actually change? As I mentioned, retrospectives are critical for the team and probably the most efficient way to improve not only the process but also team motivation and teamwork. Therefore, the big question that remains here is how to make each retrospective better than the previous one. To answer this question I’ve created a list of tips that helped me throughout the years that I hope will help you.


A safe environment is key

Retrospectives allow team members to share impediments that hold them back from achieving their full potential. As such, team members must feel safe to share their insights about any problem that they see. If the meeting environment does not allow them to feel comfortable and safe to share those insights, chances are that they will choose not to share. This makes it impossible to mitigate problems and achieve continuous improvement.

A few things that can help:

  • Once you recognize that a team member has nothing to say, have a 1:1 conversation post meeting to understand the real cause. Team members that do not share information are most often the ones that have the biggest contribution.

  • Ensure that the meeting is conducted in a comfortable physical environment that is agreed-upon by all team members.

  • Avoid finger-pointing during the meeting. Retrospectives are not about personal blame.

Do not cancel the meeting

Although retrospectives are very important for the team, there are often times that the team will cancel the meeting because they do not have the time, power or motivation to have it. In addition, in many cases, there is an external crisis such as a critical bug in production, customer issues, etc., that force the team to cancel the meeting. The basic rule is that no matter what you must ensure that there is room for retrospectives. If you are not able to conduct it at the ordinary time (usually the last day of the sprint after the review meeting), make sure the team finds the time to conduct it the following week prior to the planning meeting. If you still cannot find the time, at the very least provide a platform for the team to share their inputs and discuss them as early as possible during the next sprint.

Are the meeting outcomes actionable?

The value of retrospectives can be measured by a simple test of how many of the items that were raised during the meeting were implemented. This shows the team that there is an remedy for their problems. What team members will want to participate if there are no real answers or improvements for their items? To provide good solutions, we must make sure to start from the basics.

What do I mean by basics?

  • Start with documenting those problems that allow tracking (an impediment backlog is a good start).

  • Make sure to prioritize the items that provide the most ROI for the team, and always let the team decide which items are most important to them.

  • Make sure that each item can be mitigated with a practical action plan; items that cannot be mitigated with an action plan must be re-discussed and broken into smaller items.

  • Set the goals, and do not commit to items that you cannot really handle.

  • Make sure to show the team the improvement from the previous sprint

By following these simple steps, I can assure you that your retrospectives will become much more efficient and result in increased collaboration from the team.

Break the Ice if needed

The best retrospectives that I have taken part in were ones in which every team member had the confidence to say whatever he or she wanted to without being judged by the other team members. Retrospectives will never be as good as they can be when team members do not feel comfortable, confident and in a safe place.

A few things that can help:

  • The scrum master should start the meeting with general clarifications about the meeting’s rules of engagement and ensure that every member feels safe enough to speak.

  • The scrum master should start with his or her own thoughts about the previous sprint if no other team members volunteer to break the ice. If you do this, chances are that the rest of the team will feel confident enough to share as well.

  • Another option for breaking the ice is by asking the team a simple question, such as “How do you feel today?” or “Does anyone want to start to share their thoughts?” or “It was a great sprint for us; what do you think?”

Facilitation is the foundation of every great retrospective

The facilitation process is relevant to all scrum meetings but is particularly relevant to retrospectives. Why is that, you may ask. What is the difference between this and other meetings? Well, besides the obvious differences, there is one thing that pops out. Retrospectives are strictly owned by the team; external stakeholders are not allowed in (which they are in all other meetings as contributors or silent observers).

A few things that can help:

  • Don’t invite any stakeholder who could influence the team’s freedom to speak. Ensure that external stakeholders that arrive without notice do not take part.

  • Ensure that all team members are familiar with what is expected from them during the meeting.

  • In case the team wants to add external stakeholders (which is possible with the approval of all team members), make sure that they know the meeting rules and what is expected of him.

  • Make sure all team members arrive prepared for the meeting.

Review progress from the last retrospective

The main target of a retrospective is to help the team flourish while removing the impediments that hold them back. One of the keys to increasing collaboration and team motivation is to show them their progress since the last retrospective. The team will be more motivated to participate if they see that their ideas, complaints, and words actually mean something and were not made in vain. As part of each retrospective, the team can share many items that they want to improve that require smaller changes or share only a few items that require more effort of one or more sprints. Now, the thing that really matters here is that you show some kind of progress, even when you do not have the complete solution for their problems. Keep in mind that each item is prioritized and you therefore need to address the most important items first. If the top items are blocked, do not wait but start mitigating the other, less prioritized items and move back to the top prioritized items when possible.

Make sure you cover the positive aspects

Unfortunately, many teams that focus on their problems forget to talk about the things that went well and that they want to keep. Talking about what went well motivates the team by showing them the things that helped them succeed and maintains the team’s good habits of collaboration and hard work. Talking about the positive aspects also allows the team to see that there always are positive aspects. My suggestion is that you always create a balance and discuss both the positive and negative aspects. During this time, you should show the team how the negative items (that were mitigated) became strengths and not weaknesses. Tracking will provide the best platform to get the team to understand the importance of the meeting and its benefits.

Rotate the meeting facilitator

The scrum master is usually responsible to facilitate scrum events, but I believe that this may be more relevant to new teams that just started an agile transformation and are still not self-organized. Once the team becomes self-organized, there is no reason for the scrum master to remain the meeting facilitator. In my opinion, it is a good idea that the meeting facilitator be changed each retrospective. By following this practice, the team will gain more ownership of the process and will want to participate because they know that they can really impact the team’s empowerment. Once you decide to follow this practice, it’s important that you let each member conduct the meeting following their own personal approach and agenda (under the clear boundaries of the meeting), which will help increase their motivation to succeed as meeting facilitators.

How efficient is your retrospective?

A common failure of agile teams is their inability to determine how efficient their retrospective really is. It is important that the team includes items on the retrospective itself to determine if they can improve it or not. Questions that I usually use during retrospectives are:

  • Do you think that our retrospective is efficient enough?

  • Is there anything that you want to change in the process of the next retrospective?

  • At the end of the meeting, can you share feedback on the meeting?

Retrospectives in a different location

One thing that I’ve found to be very helpful in boosting creativity, brainstorming, and motivation is to conduct retrospectives in different locations once in a while. Conducting the same meeting in the same location creates a sense of routine that we do not want to see in agile teams. My suggestion is to take the meeting outside the office every two to three retrospectives, such as at a coffee shop or at the beach. Just give it a try, and I assure you it will be worth it.

Root Cause Vs. symptoms

Retrospectives are made to allow each team member to share the impediments that affected their ability to succeed. Therefore, when looking at what needs to be improved, there is a very important rule that I always make sure to keep, and that is to understand the root cause of any item and not just its symptoms, which is usually what is provided in the original input.

The best example for this issue is if there is similar input every sprint. There are many reasons for this, and it’s important to correlate between the items to see that you simply cannot fix the issue without understanding its root cause.

There are many techniques that you can use for root-cause analysis (RCA), which I will share in subsequent posts, but one approach that always works is RCA using the 5 whys (just search for it and you will see why).