How Many Teams Can a Scrum Master Effectively Support? An Agile Maturity and Effort Model

This article addresses a common question for companies beginning agile transformation: how many teams can a Scrum Master (SM) effectively support? It begins by reminding readers that "results are the best proof" and that this principle also applies to the SM workload question.

The discussion explains that the issue stems from the nature of the SM role, which is often described vaguely in Scrum literature. Because the SM acts as coach, protector, and facilitator, it is difficult to define concrete deliverables, leading to misunderstandings at the executive level.

When executives or teams do not fully understand agile, they may ask, "What does an SM actually do?" Good teams recognize the SM as a facilitator, while less mature teams treat the SM as a servant who performs miscellaneous tasks.

Agile Maturity and Effort Model

The author presents a diagram that maps team agile maturity (horizontal axis) against the effort required from the SM (vertical axis). Team agile maturity is defined as the team's understanding of agile and its ability to work in an agile manner, encompassing developers, SMs, and Product Owners (POs). The SM effort represents the time and attention the SM must invest in guiding and training the team.

The model shows a curve where SM effort initially rises with increasing maturity, reaches a peak, then drops sharply after a certain point. Four key lines are highlighted:

E1: Effort level when the team is early in its agile journey and maturity is low.

E2: Effort level when the team has reached a higher maturity; effort is lower than at E1.

M1: A vertical line indicating a specific moment of team maturity; SM effort is the same at M1 and M2.

M2: Another vertical line; between M1 and M2 the SM effort shows no clear pattern.

Interpretation of the model:

SM effort is linked to team agile maturity. When maturity is low, SM effort is low. As maturity rises, SM effort gradually increases to a peak. After the peak, effort fluctuates irregularly (M1 to M2). Beyond the second M2 stage, SM effort drops rapidly, eventually falling below the initial level.

Why the Curve Looks This Way

In the early transformation stage, teams have low agile maturity and view the SM as a monitor. The SM’s primary task is to gain trust, focusing on mindset change, observation, and limited agile practices, while also handling traditional project manager duties to ensure delivery. This corresponds to the E1 state.

As the team’s maturity and trust in the SM grow, the SM can introduce more agile practices and guide the team more freely, moving toward the M1 point where the SM acts as a de‑facto leader.

Later, the SM shifts responsibilities to the team, becoming a coach who teaches the team to guard the process. The effort stabilizes while the nature of work changes from 100% process guarantee to a balanced split, eventually reaching 0% process guarantee and 100% team coaching (M2 point).

Finally, once the team is highly mature, the SM’s workload drops sharply because the process runs smoothly and the team can resolve many issues independently. The SM becomes more of a mascot or consultant, stepping in only when needed.

Practical Guidance on Team Count

The author’s personal judgment is that a Scrum Master should not handle more than three teams, preferably no more than two, especially for critical projects. Managing three teams would extend daily stand‑up meetings to 45 minutes and create a 30‑minute time gap between the first and last team, leading to inefficiency.

When resources are tight, a SM can support 1–1.5 teams; if necessary, up to two teams can be managed, but supporting three teams requires additional hiring to avoid burnout as team maturity increases.

If all teams reach the E2 stage where SM effort is minimal, the organization can consider reallocating the SM to new teams, training a junior SM, or assigning SM responsibilities to a developer, depending on headcount and culture.

In summary, the SM’s effort follows a predictable curve tied to team agile maturity, and the optimal number of teams per SM is generally two, never exceeding three without risking reduced effectiveness.