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:
- Insufficient transparency
- Focus on one-time problems or successes
- Over-representation of Product Owner
- Self-management problems
- Too many commitments
- Common mistakes during a Sprint Retrospective – Summary
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.
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 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.
- Glossary of basic terms, roles and notions
- What is Scrum?
- Scrum values
- How to implement Scrum in your company?
- Scrum Team - what is it and how does it work?
- Who is a Product Owner?
- The most common mistakes of Product Owner
- Who is the Scrum Master?
- Characteristics of a good Scrum Master
- The most common mistakes of Scrum Master
- What statistics and metrics should the Scrum Master track?
- Cooperation between Product Owner and Scrum Master
- Development Team in Scrum
- The most common mistakes of Developers
- Scrum artifacts
- Scaling Scrum
- Sprint Backlog
- What is the Product Backlog?
- What are User Stories?
- Creating the best User Story with INVEST
- The most common User Story mistakes
- User Story Acceptance Criteria
- Estimation and Story Points in Scrum
- Planning Poker
- Team Estimation Game
- Defining Increment
- Scrum events
- What is Sprint in Scrum?
- Scrum Team Commitments - Product Goal, Sprint Goal and Definition of Completion
- What is a Burndown Chart?
- How to create and interpret a burndown chart?
- Advantages and disadvantages of the burndown chart
- Kanban boards in Scrum and Scrumban
- Velocity in Scrum - Speed of the Development Team
- Daily Scrum
- Sprint Planning
- Sprint Review
- What is a Sprint Retrospective?
- Common mistakes during a Sprint Retrospective
- Product Backlog nurturing