Choosing the Optimal Size for a Scrum Team
Written on
In my memory, the most challenging meeting with a client remains vivid. It involved a public sector organization with 26 participants from various departments, each with distinct interests. After about thirty minutes, I realized I was only engaging with five individuals, while the rest were engrossed in their side conversations, completely oblivious to the agenda. Both they and I were squandering our time.
This scenario mirrors the dynamics of Scrum Teams. An inappropriate size and composition can severely hinder productivity and lead to inefficiencies. What guidelines can we follow?
According to the Scrum Guide, a Scrum Team typically does not exceed ten members:
> “The fundamental unit of Scrum is a small team of people, a Scrum Team (…) The Scrum Team is small enough to remain nimble and large enough to complete significant work within a Sprint, typically 10 or fewer people.” — Scrum Guide 2020
There isn't a one-size-fits-all solution. Choose a configuration that suits your team, experiment, and refine as needed. Flexibility is key.
However, it's not that simple. While experimenting with meeting formats is feasible, adjusting the Scrum Team's size is more complex. How many Sprints would you require to explore all potential configurations? What impact would these changes have on your team (consider the stages of Forming, Storming, Norming, and Performing for Agile teams)? Furthermore, how much insight can you genuinely gain from a single-Sprint trial in team structure?
Indeed, the answer often comes down to context. Yet, numerous individuals frequently inquire about these variables. Instead of starting from scratch, it is prudent to learn from others' experiences, implement those insights, and adapt accordingly.
Before drafting this article, I conducted three LinkedIn surveys, engaged with eight seasoned Scrum Masters, Agile Coaches, and a Product Owner mentioned at the conclusion, and interviewed over twenty individuals on LinkedIn.
Without further delay, let’s examine some extreme cases.
1. The Smallest Viable Scrum Team
The concept of a team dedicated to a product with clearly defined roles — Scrum Master, Product Owner, and Developers — is essential for Scrum’s effectiveness.
> “The fundamental unit of Scrum is a small team of people, a Scrum Team. The Scrum Team consists of one Scrum Master, one Product Owner, and Developers.” — Scrum Guide 2020
Some contend that these roles inherently have conflicting interests, leading to unavoidable disputes. I beg to differ. Isn’t it true that the entire team must work towards a shared objective to succeed? Each role simply emphasizes different aspects of the work.
The Product Owner focuses externally, advocating for increased value delivery. However, achieving these goals is impossible without the Developers who contribute to the product's tangible aspects. The Scrum Master facilitates the team’s efforts in a complex environment, promotes understanding of empirical process control, and underscores the importance of quality.
The notion of conflicting interests is unfounded. The entire team either succeeds or fails together.
One-Person Scrum Team
According to the Oxford Dictionary, a team is defined as:
> “Two or more people working together.”
The Scrum Guide also consistently refers to Scrum Team members in the plural form, emphasizing collaboration.
If you find yourself working solo due to organizational decisions, you are likely experiencing the “hero developer” anti-pattern. A single individual must juggle all three responsibilities. I once operated this way in a company, and it left me with no time to focus on productive work. It was far from ideal.
Many assert they “use Scrum” to pursue individual goals. If you can tackle complex challenges independently, apply empiricism to progress, set both short- and long-term objectives, maintain a backlog, and work iteratively, you're likely on the right track.
However, this setup lacks collaboration, interactions, and team dynamics. Leadership is absent. If you are the only stakeholder, holding separate events like Sprint Review and Sprint Retrospective may not be beneficial. Is this still within the Scrum Framework?
Two or Three Scrum Team Members
With three Scrum roles (Product Owner, Scrum Master, and Developers) in a two-member team, at least two roles must be combined.
This is acceptable. These are responsibilities, not mere job titles. The Scrum Guide does not prohibit the Scrum Master and Product Owner from being the same person within the Scrum Team. It also allows for the Product Owner or Scrum Master to take on Developer duties.
In a team of three, it is challenging to envision a scenario where the Product Owner and Scrum Master only participate at the start and end of the Sprint, occasionally attending the Daily Scrum, while the sole Developer works in isolation. This setup lacks coherence. In smaller teams, it’s common for Scrum roles to be combined, leading to scenarios where the Scrum Master or Product Owner also functions as a Developer.
Moreover, we must consider the importance of cross-functionality, essential for minimizing external dependencies:
> “Scrum Teams are cross-functional, meaning the members have all the skills necessary to create value each Sprint.” — Scrum Guide 2020
Additionally:
> “The Scrum Team is (…) large enough to complete significant work within a Sprint.” — Scrum Guide 2020
In certain fields, achieving cross-functionality that allows a team to deliver meaningful work within a Sprint may necessitate larger groups. But how large should they be?
2. The Largest Possible Scrum Team
There is no strict upper limit on Scrum Team size. Nonetheless, the Scrum Guide emphasizes the benefits of smaller teams:
> “In general, we have found that smaller teams communicate better and are more productive.” — Scrum Guide 2020
This can be illustrated by examining the interactions among team members. As more individuals are added, the number of communication lines increases exponentially:
A larger team means each member navigates more interactions, communication issues, and varying interests. Since Scrum aims to manage complexity, introducing excessive complexity related to team members can be counterproductive (reminiscent of my meeting with 26 participants).
If your team grows too large, consider restructuring into smaller, cohesive units:
> “If Scrum Teams become too large, they should consider reorganizing into multiple cohesive Scrum Teams, each focused on the same product. Therefore, they should share the same Product Goal, Product Backlog, and Product Owner.” — Scrum Guide 2020
However, even after restructuring, the question of the optimal size remains pertinent.
3. The Best Size and Composition of the Scrum Team
Scrum Guide 2017 and Scrum Guide 2020
Let’s reflect on past guidance. The Scrum Guide 2017 recommended a Development Team size of 3 to 9 members, equating "Development Team" with "Developers" as defined in the Scrum Guide 2020.
> “Fewer than three Development Team members decrease interaction and results in smaller productivity gains (…) Having more than nine members requires too much coordination (…) The Product Owner and Scrum Master roles are not included in this count unless they are also executing the work of the Sprint Backlog.” — Scrum Guide 2017
The updated Scrum Guide 2020 states “typically 10 people or less.” This shift appears to be a move towards less prescriptive guidance, accommodating “many domains holding essentially complex work, beyond software product development where Scrum has its roots” (Scrum Guide 2020).
The 2017 guide indicated that having too few team members (fewer than 3 Developers) could actually reduce productivity rather than enhance it.
While the current guidelines no longer mandate a minimum of three Developers, I still view this as a valuable recommendation.
Scrum Team Survey
To further investigate Scrum Team size and composition, I gathered additional information.
On February 2, 2022, I launched a survey on LinkedIn:
On February 7, 2022, I conducted another survey:
Subsequently, I conversed with 17 individuals who selected the "Other" option, often regarding the combination of Product Owner and Scrum Master roles. None viewed this combination as successful.
The insights were intriguing but statistically limited. On February 12, 2022, I initiated a third survey:
The combination of Product Owner and Scrum Master was deemed successful in fewer than 26% of responses (15 out of 59).
These results align with my interviews and feedback received. One comment I noted was:
> “I’ve done both at the same time, and when you don’t have too many teams (1–2) you can pull it off. And you need to have sufficient expertise to carry the weight of both roles, and I believe few people can do that. I see enough struggling POs who would sink with more responsibility.”
> “The problem isn’t lack of time. The problem is lack of expertise. I have sufficient skills to perform both, but I definitely am not as good as a Scrum Master.”
> “I believe I am a better Product Owner, but the problem was definitely not time problems or too much stress.”
> “There are enough people who struggle just being a good Product Owner or Scrum Master. I believe it won’t work in many cases.” — Maarten Dalmijn
Furthermore, the Scrum Master’s role includes coaching the Product Owner:
> “The Scrum Master serves the Product Owner in several ways, including:”
> Helping find techniques for effective Product Goal definition and Product Backlog management;
> Helping the Scrum Team understand the need for clear and concise Product Backlog items;
> Helping establish empirical product planning for a complex environment; and,
> Facilitating stakeholder collaboration as requested or needed.”
— Scrum Guide 2020
Roy Klein aptly stated, “if you are the Product Owner and the Scrum Master, then you need to be such a good Product Owner to require no coaching.”
Summary
Here are my insights:
- A typical Scrum Team comprises 5 to 10 members.
- If the team has fewer than 5 members, I would exercise caution with only 1 or 2 Developers (refer to Scrum Guide 2017 as a recommendation).
- In most scenarios (79%), Scrum Masters and Product Owners are not Developers.
- It is common to blend different responsibilities in smaller teams, as evidenced by my experiences and numerous discussions in recent weeks.
- Merging the roles of Product Owner and Scrum Master can be challenging, with only 26% of survey participants finding it successful. Separating these roles may yield better results, although further research is necessary.
To ascertain the best size and composition for a Scrum Team, consider the following:
- Cross-functionality: Do members possess “all the skills necessary to create value each Sprint” (Scrum Guide 2020)? If not, they may find themselves waiting on others, which constitutes Lean waste.
- Are they capable of “completing significant work within a Sprint” (Scrum Guide 2020)? Larger teams tend to be less productive, meaning that delivering the same value incurs higher costs due to increased communication complexity. However, delivering value later also carries costs, such as regulatory risks or lost profits.
- How complex is the problem at hand? I prefer smaller, agile teams whenever possible. Conversely, more intricate problems often necessitate a broader range of skills and competencies, necessitating a balance.
- What happens if team members fall ill during a Sprint? Can others step in?
- It’s also beneficial to consider “collective intelligence,” which arises from collaboration and often exceeds the individual intelligence of team members. If you’ve ever participated in an escape room, you’ll understand this concept well.
4. Final Thoughts None of the assertions in this article are absolute truths. If your situation diverges, don’t hesitate to step outside your comfort zone. Embrace experimentation. If you find a configuration that, while not strictly adhering to Scrum principles (e.g., lacking a Scrum Master, having two Scrum Masters, or two Product Owners), proves effective for you, that’s perfectly acceptable. The ultimate goal is not to adhere rigidly to Scrum but to deliver value.
Whatever path you choose, implement it and continuously inspect and adapt over time.