Scrum Guide | 39. Most common mistakes during a Sprint Retrospective

Sprint Retrospective is the event that ends every Sprint. And at the same time one of the most difficult Scrum Team meetings. The most common mistakes during a Sprint Retrospective involve avoiding conversations about sensitive issues, as well as the lack of concrete commitments leading to the resolution of already diagnosed problems.

Common mistakes during a Sprint Retrospective – table of contents:

1. Introduction
2. Insufficient transparency
3. Focus on one-time problems or successes
4. Over-representation of Product Owner
5. Self-management problems
6. Too many commitments
7. Common mistakes during a Sprint Retrospective – Summary

Introduction

Mistakes during a Sprint Retrospective are unfortunately very common. This is because it is one of the most difficult meetings to successfully execute as it requires a lot of maturity from the team. That’s why it’s worth taking a look at the problems that occur most often in other teams so that you can more easily spot their symptoms when conducting Sprint Retrospective in your Scrum Team.

Insufficient transparency

According to the Scrum Guide, each member of the Scrum Team is obliged to be honest and bold in expressing concerns and to voice their opinion during the Sprint Retrospective. However, in practice, the commitment to transparency is very demanding. Because of this, Scrum Team members often try to circumvent it.

One problem that is difficult to spot and solve is avoiding discussion of observed shortcomings in the Scrum Team’s work. This can lead to much more serious problems in the long run.

The Scrum Master’s task, therefore, is to keep a close eye on the situation in the team and encourage all team members to be proactive from the very beginning of the Sprint Retrospective.

Focus on one-time problems or successes

Another problem that can arise during Sprint Retrospective is paying insufficient attention to cyclical and repetitive team behaviors, and their impact on team effectiveness.

It’s always good to congratulate Scrum Team members if they have achieved exceptional success. However, Sprint Review should not be dedicated to celebrating it. The same is true of failures. If something failed due to fortuitous reasons or an already diagnosed error, it is not worth over-analyzing the event during Sprint Review.

Sometimes, however, the team devotes a large part of the Sprint Retrospective to such events. Keep in mind though, that the purpose of Sprint Retrospective is to look for ways to improve the team’s daily work. Therefore, the meeting should not revolve around one-time successes or problems that are highly likely not to happen again.

Over-representation of Product Owner

In many organizations, the position of Product Owner is equated with that of Product Manager. Product Owner is then often considered the supervisor of the Scrum Team. For this reason, it happens that the Development Team does not want to talk about teamwork problems in his presence.

That is why it is so important to build mutual trust between the Development Team and the Product Owner. Unfortunately, the process of building trust is difficult and lengthy. That’s why sometimes it’s a good idea for the Product Owner to give up participation in all or part of the Sprint Retrospective to leave space for the rest of the team to discuss freely.

Self-management problems

Self-management means that Scrum Team members make their own decisions about who among them will perform certain tasks, when and how. During Sprint Retrospective, the team discusses people, their interactions as well as team practices. It then decides what problems need to solve in the upcoming Sprint, how to do it together with who will bear responsibility for taking action.

If more serious problems arise in a self-managing team, there may be a temptation in the Scrum Team to abdicate responsibility.

Occasionally, team members don’t want to take part in the discussion and try to push the management responsibility onto someone else. To prevent this, it is extremely important to discuss even small problems regularly to prevent their accumulation.

Too many commitments

An active Scrum Team operating following the three pillars of empiricism: transparency, inspection and adaptation, may encounter the problem of making too many commitments at once.

If the commitments made by the Scrum Team during a Sprint Retrospective are too many, there is a considerable risk that:

• none of the commitments will be implemented properly
• some commitments will not be implemented at all
• the changes made will not be permanent

Therefore, a good practice is to undertake no more than four improvements in each Sprint. This allows for a gradual but effective improvement of the team’s performance.

Common mistakes during a Sprint Retrospective – Summary

Since Sprint Retrospective is a challenging event, problems often arise during its conduct. To deal with them more easily, it is worth noting the ones that arise most often. Common mistakes during a Sprint Retrospective are:

• insufficient transparency – when Scrum Team members fail to deal with honesty in more difficult team situations
• focus on one-off problems or successes – when Scrum Team members focus on discussing successes and failures, instead of discussing the long-term effectiveness of the team’s work
• Product Owner over-representation – when Scrum Team members treat the Product Owner with limited trust as if he or she were someone outside the team or a supervisor
• self-management problems – when Scrum Team members try to shift responsibility for problems and decision-making.

If you like our content, join our busy bees community on Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.