top of page

Five Signs You Are not a Scrum Team

Updated: May 31, 2022

Everyone is a on a team these days, it seems. Or so they say. Many people aren't really though. Many "teams" I have encountered are at best groups.

If you use Scrum this matters. Scrum was created with teams in mind. For Scrum to work, it demands a team.

Before getting ahead of ourselves and listing telltale signs you are a group and not a team, let's look at the difference.

Short version: groups cooperate, teams collaborate.


When you cooperate you work in the same context solving different aspects of the same problem. Sometimes you choose to cooperate because it fits your personal agenda, but you might have very different goals.

police arrest
The officer probably asked the guy to cooperate, but they have very different agendas


When you collaborate you solve the same problem together. You have the same goal. For this to work you need to have a shared understanding of the problem. You need to synchronize and communicate.

Indications You Are Not a Team

Only one of these items does not automatically mean you are not a team, but they are worth reflecting on. If you see several in your "team" you should probably think about if you really act and work as a team. And if you want to.

1. Everyone Working On Separate Backlog Items

If everyone works on different items in the backlog, you work in the same context but on different aspects of the problem.

2. Mini Waterfalls in the Sprint

When a backlog item is handed over between people inside an iteration it becomes a miniature waterfall.

There will always be handovers, but the norm should be to work on the same item together at the same time. Handovers should mostly happen iteratively with fast feedback loops.

Difference waterfall and agile

A common antipattern is that stories are handed over to testers at the end of the sprint.

This is in a way a manifestation of the first item, but instead of dividing work between people with the same role (for example programmers working on separate stories) you divide work between different roles. God forbid you do both, right?

3. Separate Estimations Based on Type of Work

As a consequence of dividing work between people and roles, perhaps it makes sense for everyone to also do their own estimation of the work.

If you use relative estimations like story points and create different estimates based on type of work or who does the work - or if you consistently separate items into for example development and testing - you are going about it all wrong.

4. Scrum Events Feel like a Waste of Time

If you are a group (not a team) there is a big chance Scrum events feel like waste. I mean, what's the point of listening to Mike talking about that story he works on, and why spend so much time understanding and discussing the Sprint backlog when I only work on this one story anyway.

On the other hand, if you collaborate and work together on the same stuff, listening to Mike makes perfect sense. With a team mindset you are likely going to get involved, too, and you should feel a shared responsibility for the team's outcomes. Not only for your own contributions.

When you feel a shared responsibility for the team's work, talking about how you work also becomes way more interesting. Which brings us to the last item on the list.

5. No Conflicts

If everyone works on separate items, if you aren't dependent on what the others do, and if you don't feel a shared responsibility for the team's deliveries, no reason to get into arguments.

As soon as you start depend on each other, work together and care about the total outcome, conflicts will ensue. Groups can be really creative in avoiding conflict though. For example, if there's tension in the team an easy way out can be to - deliberately or not - create more or less isolated subgroups within the team.

Obviously outright war is not desired but it's important that you can have open honest discussions on a foundation of trust and safety. If people get affectionate and the discussion heated it is a sign that they care about what they do. A mature team and a good coach can help make sure discussions stay productive and don't escalate too far.


Putting a bunch of people in an office area and handing them a backlog does not equate to a team. To be a team you need to work together and have a shared understanding of the problem at hand, as well as a shared mission and goal. You also need to feel a shared responsibility for the entire team's deliveries, and put the team's goals and results before your own. It doesn't happen automatically, and it's not easy, but if you have ever experienced working in a true team you know that it is worth the effort ten times over.

Do you recognize any of this from your own team? And what do you think, are you a team or a group? And if not a team, is it a problem?


Premade trainings on agile or a course tailored to your needs?

Product Owner

If you work as

bottom of page