As someone who spends a majority of his time working with Scrum teams and Scrum Masters, one of the most common questions that I'm asked is “how many teams can a Scrum Master work with?”.

However, despite how common this question is, there is no simple answer. The Scrum Guide, often our first stop in our journey for questions about the Scrum framework, is silent on this matter. And while a quick internet search will turn up plenty of opinions on the subject, those opinions are usually based on the commenter's unique experience in their specific situation rather than applicable to a wide range of situations.

The fact is that there is no universal answer to this question. The right answer for your organization is going to depend on many factors, such as the skill of your Scrum Master, whether or not that Scrum Master is focused on the Scrum Master role full-time, the maturity of the team that the Scrum Master is assigned to, and of course, the maturity of the overall organization.

However, despite the uniqueness of each situation, there are some rules of thumb that seem to apply in the majority of situations. We can use these rules as a starting point, and then adapt our approach based on what we discover about our specific environment.

Laying the Ground Rules

As a general rule, a skilled Scrum Master can work effectively with 2 to 3 teams. However, there are a few caveats with this generalization.

The first caveat is that I'm assuming that this individual is focused on the Scrum Master role full-time. This means that the individual is not splitting their attention between the Scrum Master role and another role on the Development Team, such as coding or testing. Individuals described by the latter statement can only work with one team at a time: their own.

The second caveat is that I'm assuming that the Scrum Master has a reasonable level of experience and has grown their skills while acquiring that experience. While I'm hesitant to recommend a specific amount of experience, 2 to 3 years of experience across various teams seems to give Scrum Masters the opportunity to grow the skills they need to be successful in a majority of situations. In any case, you should be wary of assigning more than one team to a first time Scrum Master.

The Dangers of the Extremes

Let's dive a bit deeper into the recommendation of 2 to 3 teams to understand better from where this idea comes. First, let's look at the extremes.

For a full-time Scrum Master who is reasonably skilled, working with only a single team is often not enough to keep that individual from becoming bored with their role.

In some cases, this will simply lead to the Scrum Master becoming disengaged and neglecting their responsibilities to the team and their organization. However, in other cases, the Scrum Master may try to invent responsibilities to fill their excess time, often creating low-value work for themselves and, by extension, their teams. The number of metrics that a Scrum Master has conceived of for their teams is often a good indicator of this situation. While some metrics can provide value to the overall planning and tuning of a Scrum team, metrics covering every square inch of available wall space are often a sign of a Scrum Master with too much time on their hands.

Now let's take a look at the other extreme. Generally speaking, when a Scrum Master is asked to work with more than 3 teams they often find themselves spread too thin to add value to any of those teams.

To be truly effective with their teams a Scrum Master must be embedded in those teams. This embedding not only gives the Scrum Master the opportunity to spot friction points or opportunities for improvement, but it also helps the Scrum Master build empathy for those teams by experiencing first-hand the trials and tribulations that the rest of the team experiences on a daily basis.

If a Scrum Master is spread between any more than 3 teams, then it's highly unlikely that they will spend enough time with those teams for those things will happen.

Finding the Sweet Spot

As a result, the sweet spot for Scrum Masters who work with multiple teams is usually between 2 and 3 teams.

Giving a Scrum Master the opportunity to work with multiple teams helps that Scrum Master grow in their craft more quickly, as they have the opportunity to deal with a wider range of challenges as well as see different perspectives on how each team implements the Scrum framework.

But there's also another, more subtle benefit. When a Scrum Master works with multiple teams, they're also more likely to shift their perspective from that of an individual team towards a more holistic view of their entire organization. As a result, the Scrum Master is better able to seek out opportunities to apply the Scrum framework in their broader organization, therefore improving the lives of more teams than simply their own.

Diving Deeper Into a 2 to 3 Team Scenario

Now that we have a better understanding of why 2 to 3 teams may be the sweet spot for a Scrum Master working with multiple teams let's unpack of the details of each of these scenarios to understand better how each may work.

More often than not, a Scrum Master working with 2 teams is the sweetest of the sweet spots. In this scenario, the Scrum Master can spend significant time with each team and truly immerse themselves into the challenges those teams are facing.

Ideally, in this scenario one of the teams will be more mature than the other, which allows the more mature team to operate with more independence giving the Scrum Master more time to focus on the team that's more likely to struggle. In addition, this also provides the Scrum Master the opportunity to consider the juxtaposition of the two teams which can inspire new lines of thought or experimentation.

Expanding on the concept of working with teams of different skill levels, in a 3 team scenario ideally one, if not two, of those teams, are already mature and relatively independent. This allows the Scrum Master to serve in more of a support role for the two maturing teams which frees them to focus on the immature team. However, as the move from 2 teams to 3 teams can be more challenging than you might originally expect, having a highly-skilled Scrum Master in the mix is even important in this scenario.

Note that in both the 2 and 3 team scenarios, the Scrum Master is intentionally electing to spend less time with their more mature teams. While at first, this might surprise you, remember that at all times a Scrum Master should be preparing their teams to operate more and more independently, therefore, lessening their dependence on their Scrum Master. Intentionally lessening their involvement with their teams, while still remaining available to provide support where necessary, is a great first step in this direction.

Finding Your Own Sweet Spot

Remember that above all, the scenarios that I've outlined above are nothing more than guidelines. Every organization is different, every team is different, and most importantly, every Scrum Master is different.

While I'm hopeful that this guidance may be of some help in your own planning for the Scrum Master role remember that, as with all things agile, the only sure path to success is through constant experimentation and learning. You'll need to experiment in your own organization to find the optimal arrangement for your teams as well as expect the most optimal arrangement to shift over time as your teams evolve.

The guidance above should be considered nothing more than a starting point. Only your teams can tell you which approach will work the best in your organization.

Are you new to the Scrum Master role and are just trying to find your way? Or, are you an experienced Scrum Master who has your feet wet but now you're ready to take your craft to the next level? Check out my course series, Using the Scrum Framework from Pluralsight, to learn how to set yourself apart as a Scrum Master and help your team reach their highest potential.

Don't have a Pluralsight membership yet? Try the entire Pluralsight course catalog free for 10 days here.