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.

Common mistakes during a Sprint Retrospective

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.

Scrum Guide | 39. Most common mistakes during a Sprint Retrospective caroline becker avatar 1background

Author: Caroline Becker

As a Project Manager, Caroline is an expert in finding new methods to design the best workflows and optimize processes. Her organizational skills and ability to work under time pressure make her the best person to turn complicated projects into reality.

Scrum Guide:

  1. Glossary of basic terms, roles and notions
  2. What is Scrum?
  3. Scrum values
  4. How to implement Scrum in your company?
  5. Scrum Team - what is it and how does it work?
  6. Who is a Product Owner?
  7. The most common mistakes of Product Owner
  8. Who is the Scrum Master?
  9. Characteristics of a good Scrum Master
  10. The most common mistakes of Scrum Master
  11. What statistics and metrics should the Scrum Master track?
  12. Cooperation between Product Owner and Scrum Master
  13. Development Team in Scrum
  14. The most common mistakes of Developers
  15. Scrum artifacts
  16. Scaling Scrum
  17. Sprint Backlog
  18. What is the Product Backlog?
  19. What are User Stories?
  20. Creating the best User Story with INVEST
  21. The most common User Story mistakes
  22. User Story Acceptance Criteria
  23. Estimation and Story Points in Scrum
  24. Planning Poker
  25. Team Estimation Game
  26. Defining Increment
  27. Scrum events
  28. What is Sprint in Scrum?
  29. Scrum Team Commitments - Product Goal, Sprint Goal and Definition of Completion
  30. What is a Burndown Chart?
  31. How to create and interpret a burndown chart?
  32. Advantages and disadvantages of the burndown chart
  33. Kanban boards in Scrum and Scrumban
  34. Velocity in Scrum - Speed of the Development Team
  35. Daily Scrum
  36. Sprint Planning
  37. Sprint Review
  38. What is a Sprint Retrospective?
  39. Common mistakes during a Sprint Retrospective
  40. Product Backlog nurturing