7 signs of trouble in the Scrum Team
September 26, 2022 • ⌛ 7 min
Scrum or other Agile practices have been really popular in the last 10 - 20 years. More and more organisations decide for the “Agile transformation”. What does it mean in reality? In many cases it means only a change of language that it’s used in the organisation, but mentality remains the same.
Thankfully there are companies which really want to make an impact and change the way they think, work & deliver their products. Of course, change is the process and they cannot implement Scrum or any Agile practices without making mistakes.
Today I would like to list 7 signs of trouble in the Scrum Team. Be careful if you notice them in your Scrum Team. It probably means that some elements of Scrum have been lost in implementation. But don’t worry! You can always use empiricism and inspect & adapt.
1. Product Owner or Scrum Master assigning the work
One of the huge differences between old-fashioned waterfall product delivery & Scrum is self-management or self-organisation of the Scrum Team.
Whenever you notice that either Product Owner or Scrum Master assign product backlog items to individuals, it’s always a bad sign. It means that the team doesn’t have the autonomy to decide how they will be working and they are not self-managing.
Product Owner should only let the team know WHAT needs to be done, but HOW exactly it will be done and WHO will be working on specific items, should be up to Developers within the Scrum Team.
Scrum Master also shouldn’t control the team and assign work to anyone. They should be the person who is guiding the team and teaching them how to be self-managing. I know that it’s easy to say, but many Scrum Master who were Project Managers struggle with letting control go. But there is no other way if you really want to help the team.
2. Lack of transparency
What do I mean by “lack of transparency”? Oh God! There are so many things that people can hide!
One of the bad signs is if people in Scrum Team talk about the issues behind someones back instead of discussing it with the whole team on Sprint Retrospective. It can mean that the team doesn’t trust each other enough to discuss the issues.
Issues with transparency can be also related to communication with business e.g. The Scrum Team is hiding issues related to development of the product and business thinks that everything is ok.
In both scenarios, issues will be exposed at some point and hiding things will not serve the team. I would definitely recommend being honest & discussing what the team is struggling with. Even if it will not be comfortable for people!
3. Lack of the Sprint Goal - everything is priority
Whenever I ask Product Owner or Scrum Team - “What is the top priority?” and they reply - “everything”, it is always a bad sign for me. But that’s not the end. Even if they reply that way, but they have a Sprint Goal and at the end they can select the most important Product Backlog Items, they should be ok.
The problem is when the Scrum Team doesn’t have any Sprint Goal during the Sprint and they think that everything in the Sprint Backlog is top priority.
What is the result of that? Multitasking & lack of focus during the Sprint. Sprint Goal is the great artifact, because it helps Developers to focus and it guides them in terms of any decision that is made during the Sprint.
4. Size of the Scrum Team - too big
Based on the recent version of the Scrum Guide, the size of the Scrum Team should be max. 10 people. Why?
In general, we have found that smaller teams communicate better and are more productive.
The Scrum Team that has more than 10 people is a bad sign. Most of the time it means that communication between team members doesn’t work well. Sometimes it can look like everything is ok, but in reality when the group is too large, it’s easy to miss the needs of team members and there is not enough space/time for everyone to share their thoughts.
5. Product Backlog never ready for the Sprint Planning
This issue is really common and it is definitely a sign of trouble. If the Product Backlog is not ready for Sprint Planning and the team doesn’t know what they need to focus on next, Sprint will be probably chaotic. When I am saying ”Product Backlog is ready” it doesn’t mean that it is fully defined. I mean only that we know what the top priorities are and they are defined enough for the team to start the work.
It also means that the Product Owner should have a clear vision of the product and this will drive all the further actions. We should avoid as much as possible a chaotic Product Backlog that doesn’t serve the Scrum Team.
6. Story points translated into hours
Let me be clear - story points are not part of the Scrum. But they can be used by the Scrum Team to estimate & plan their work. But if the Scrum Team decides to use story points, they should NEVER translate them to hours. Why? The reason is really simple. Hours are absolute estimation and story points are relative estimation.
What does it mean?
Absolute estimation is reflected in absolute values e.g. hours. FYI as human beings, we are really bad at estimating complex tasks in hours.
When it comes to relative estimation, estimates aren’t just based on effort and we cannot translate them into hours. We need to take into consideration also risk, uncertainty, technology & volume.
Imagine that you decided that 1 story point means a number of hours. In this case in reality you don’t use relative estimation, it’s still estimation in hours.
Why is that a bad sign?
Translating story points into hours doesn’t really provide any value. There is no change of the behaviour, just a different label.
7. Sprint Retrospective without any outcome
That is another common issue, but I wanted to highlight it here, because it does stop Scrum Team from improving. So the most frequently used scenario is that we have a Retrospective and talk about everything what went well, what didn’t and what could be improved. The issue is when during Sprint Retrospective we just talk about issues, ideas for improvements but at the end we don’t have any clear action items.
Based on the Scrum Guide:
The Scrum Team identifies the most helpful changes to improve its effectiveness. The most impactful improvements are addressed as soon as possible. They may even be added to the Sprint Backlog for the next Sprint.
We should try to specify the changes that need to be implemented and implement them. Without it, the whole discussion was a waste of everyone’s time and Sprint Retrospective didn’t provide the value that it should provide.
Of course, if we don’t specify the action items it is a sign of something. What is behind it? Do we even have a space in the Sprint to work on improvements? Is the company supporting us in making required changes? Do we feel part of the team and have a motivation to make things better?
These are the questions that need to be addressed if we recognize the issue.
I wanted to summarise in this post signs of trouble in the Scrum Team, to help you recognize them and try to address them.
It is the end of the article, but it definitely is not the end of the signs of trouble. Have you ever experienced issues that I listed here? How did you deal with them? What would you list as other issues that could be signs of trouble in the Scrum Team?
Join our community
Sign up for newsletter to get the latest news.