## Introduction

[Scrum](/blog/first-steps-to-learn-scrum/) or other [Agile](https://agilemanifesto.org/) 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](https://letsscrumit.com/first-steps-to-learn-scrum/) or any [Agile](https://agilemanifesto.org/) 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](https://letsscrumit.com/first-steps-to-learn-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](/blog/scrum-roles-2-product-owner/) or [Scrum Master](/blog/scrum-roles-3-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](/blog/scrum-roles-2-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](/blog/scrum-roles-1-development-team/) within the Scrum Team.

[Scrum Master](/blog/scrum-roles-3-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](/blog/scrum-roles-3-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](/blog/scrum-events-5-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!

![gossip](img/gossip.jpg "gossip")

## 3. Lack of  the Sprint Goal - everything is priority

Whenever I ask [Product Owner](/blog/scrum-roles-2-product-owner/) or Scrum Team - **"What is the top priority?"** and they reply - **"everything"**, it is always a bad sign. But that’s not the end. Even if they reply that way, but they have a **[Sprint Goal](/blog/sprint-goal-why-do-we-need-it/)** 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](/pl/blog/scrum-artifacts-2-sprint-backlog) is top priority.

What is the result of that? **Multitasking & lack of focus** during the [Sprint](/blog/scrum-events-1-the-sprint). **[Sprint Goal](/blog/sprint-goal-why-do-we-need-it/)**  is the great artifact, because it helps [Developers](/blog/scrum-roles-1-development-team/) to focus and it guides them in terms of any decision that is made during the [Sprint](/blog/scrum-events-1-the-sprint).

## 4. Size of the Scrum Team - too big

Based on the recent version of the [Scrum Guide](https://scrumguides.org/scrum-guide.html), 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.

![blank notebook](img/blank.jpg "blank notebook")

## 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](/blog/scrum-artifacts-1-product-backlog/) is not ready for [Sprint Planning](/blog/scrum-events-2-sprint-planning/) and the team doesn’t know what they need to focus on next, [Sprint](/blog/scrum-events-1-the-sprint will be probably chaotic. 

When I am saying **"[Product Backlog](/blog/scrum-artifacts-1-product-backlog/) is ready"** it doesn’t mean that it is fully defined. I mean only that the top of the backlog is **defined enough** for the team to start the work.

It also means that the [Product Owner](/blog/scrum-roles-2-product-owner/) has 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](/blog/scrum-artifacts-1-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. So, 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**, so 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 fixed estimation in hours.

When we estimate with story points, these estimates will be different depending on the team, their knowledge, skills & how many things they know about the task or story. 

They estimate considering all team members. So one person can work on the story for 8 hours, because they are new and they need to learn the technology. While the other team member would work on it for 3 hours, because they are experienced and technology is simple for them.
 
This case is just one example of the way how estimates work. Estimation is also a great opportunity for [Developers](/blog/scrum-roles-1-development-team/) to discuss specific product backlog items & clarify things. 

Translating  story points into hours doesn’t really provide any value, while it adds the risk of micromanagement and verification if a specific item was completed within planned time. 

## 7. Sprint Retrospective without any outcome

That is another common issue and 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](/blog/scrum-events-5-sprint-retrospective) and talk about everything what went well, what didn’t and what could be improved. The issue is when 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](https://scrumguides.org/scrum-guide.html): 

> 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](/blog/scrum-events-5-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.

## Summary

The purpose of this post was to summarise 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?

[Embed](https://www.instagram.com/reel/Ci2YR1qjaze/?utm_source=ig_embed&utm_campaign=loading)

Have you noticed issues once implemented Scrum? Are you wondering what could change to help your team improve? Read this post and check out if you didn’t fall into one of the 7th traps I mentioned.

1 post tagged with #scrum team