In-Depth: What Is The Optimal Size For A Scrum Team?
An exploration of scientific evidence and data from Scrum teams to identify their optimal size, and practical guidelines
How many members did the best Scrum teams you worked with have? It’s an age-old question amongst practitioners who are new to Agile methodologies: “What is the optimal number of members in a team?”.
The Scrum Guide suggests that a team “should be small enough to remain nimble and large enough to complete significant work within a Sprint, typically 10 or fewer people”. But it doesn’t provide any evidence for this. Mark Levison has also written this evidence-based article about it, which is the only other evidence-based article I could find about it in our community.
Fortunately, this is a question that can be answered with data. So I decided to fire up SPSS and load the most recent dataset from our Scrum Team Survey. I also read all the relevant scientific studies I could find via Google Scholar. Let's see what the evidence has to say!
This post is part of our “in-depth” series. Each post discusses scientific research that is relevant to our work with Scrum and Agile teams. We hope to contribute to more evidence-based conversations in our community and a stronger reliance on robust research over personal opinions. As you may imagine, it takes a lot of time to compile such evidence-based posts. If you think our content is valuable, and we should write more of it, you can support us on Patreon.
Preface: About Our Data
In addition to the other scientific studies we cover in this post, we also run analyses on data from our own Scrum Team Survey. We created this tool for teams to diagnose and improve their process in an evidence-based way. You can use the free version for individual teams. For this post, we used a sample of 1.963 Scrum teams and 5.273 team members. The sample was cleaned of fake and careless responses and corrected for social desirability where relevant. Our sample includes teams from all sectors, sizes, and regions.
A strength of this dataset is that it represents real teams from across the globe that use it to identify real improvements. We performed a scientific study with Prof. Daniel Russo from the University of Aalborg to identify five core factors that explain a large part of what makes Scrum teams effective.
Finding #1: Most Teams Are Between 5 And 10 Members
In our questionnaire, teams pick the category that most closely represents their size: 1–4 members, 5–10 members, 11–16 members, or more than 16 members. This includes Product Owners and Scrum Masters. By far the most popular size lies between 5 and 10 members (70.7%), followed by 11–16 members (19.7%).
These results show that most Scrum teams are following the recommendation of the Scrum Guide to limit to 10 members. However, almost a quarter of all teams still choose to exceed that size. But this may not be an issue if performance does not suffer as a result. This is something we will investigate next.
Finding #2: Smaller Teams Perform A Bit Better, But The Differences Are Small
The first test is to see if teams of different sizes score differently on the core factors of effective teams in the Scrum Team Survey that we identified in this scientific study with Prof. Daniel Russo. These factors — continuous improvement, responsiveness, stakeholder concern, team autonomy, and management support — explain much of how effective Scrum teams are at satisfying stakeholders and team members alike.
The results from an ANOVA showed mixed results. A general trend is that teams of 5-10 members score higher on all factors than both smaller and larger teams. But this difference is only significant for responsiveness and team autonomy. Even there, the observed difference is modest — between 0.1 and 0.4 points. More importantly, there is no significant difference in how effective teams are when only their size is considered.
So while our data supports the general direction of the preference for teams of 5–10 members, the differences aren’t that substantial. The relationship between team size and team effectiveness is clearly more complex.
Finding #3: The Diminishing Returns Of Large Teams Are Well Supported By Scientific Evidence
What do scientific studies say? I went to Google Scholar, entered “team size performance” and checked “Review articles” to find 5 relevant studies. The full references are at the bottom of this post.
The general theme in these studies matches our findings. Team performance tends to increase as members are added until an optimum size is reached, and then starts dropping off (Dennis & Valacich, 1994). Smaller teams tend to be more socially cohesive and communicate and coordinate more effectively (Horwitz, 2005). Although the optimum size depends on many factors, several studies have recommended between 3 and 5 members for regular workgroups (see Horwitz, 2005). For software teams specifically, studies have shown that teams with 9 or more members are significantly less effective than smaller teams (ISBSG, 2007, Rodriguez et. al., 2012). This is also consistent with the evidence-based recommendations that Mark Levison reports, although there is also a preference for less if possible.
However, teams that are too small may lack the resources and skills to achieve their shared goals (Kozlowski & Bell, 2001). Taken together, these findings and recommendations align well with our results.
“For software development teams specifically, studies have shown that teams with 9 or more members are significantly less effective than smaller teams.”
There are many complementary explanations as to why larger teams as less effective (Kozlowski & Bell, 2001). The most common theory is that the informational channels become increasingly complex in large teams, which causes cognitive overload among members. This causes fragmentation and loss of integration in teams, which in turn diminishes their effectiveness. Such fragmentation is easy to notice in practice during a Daily Scrum with a team of more than 16 members. People just tune out or focus only on their own tasks.
Although team size does have an effect, the scientific studies also emphasize that it isn’t clear-cut and that other factors are probably more important. This is easy to understand. A team with 9 members with identical skills is probably less effective than one with 4 members with different, complementary skills. Similarly, a team of 5 members with high relational conflict will probably do worse than a team of 12 with no conflict. In other words, team size alone is a small part of the story of what shapes how effective teams are. The processes that actually happen in teams are probably more important. And I’d like to pick out one such process in particular because it seems very important.
Finding #4: Psychological Safety Is Higher In Small Teams, And Predicts A Large Part Of How Effective Scrum Teams Are
Edmondson (1999) defines psychological safety as “the shared belief that it is safe to take interpersonal risk’’. Unfortunately, many practitioners have taken this to mean that there are no conflicts in teams and people are not critical of each other. However, giving feedback and offering constructive criticism is precisely the kind of “interpersonal risk-taking” that psychological safety should be about, as is the ability to ask and give help or admit uncertainty.
Psychological safety has been demonstrated to influence learning behavior, decision quality, and performance in work teams (Edmondson, 2014). Particularly for Agile teams, there is plentiful support for a link between safety and performance (Dreesen & Hennel, 2021; Duhigg, 2016). Moe, Dingsøyr & Dybå (2010) conclude that without it “team members will expend time and energy protecting, checking, and inspecting each other as opposed to collaborating to provide value-added ideas”.
Since we also measure psychological safety in the Scrum Team Survey, we can see how this interacts with team size. Our first finding is that psychological safety becomes significantly lower as teams grow larger (see below). Now, the effect itself is modest. Teams of up to 10 members score 5.2 on average (on a scale from 1 to 7), whereas teams with more than 16 members score 4.8 on average. While the 0.4 points difference isn’t big, the overall trend is clearly descending.
What makes this more impactful is that our results also show a very strong positive effect of psychological safety on team effectiveness. In linear multiple regression, the standardized effect of psychological safety is 0.61 (on a scale from -1 to 1). This means that for each increase in psychological safety by 1 point, team effectiveness increases by 0.61 points. This is a very large effect indeed. Furthermore, psychological safety explains 37% of the variance in team effectiveness, which makes it the most powerful individual predictor of all the factors we measure in the Scrum Team Survey. It also shows many interactions with other factors in our model. So teams that operate in a climate of psychological safety seem to be much more able to satisfy their stakeholders and have high morale (which we define as “effectiveness”).
Now, the relationship between psychological safety and team effectiveness is probably far more complex than this simple analysis suggests. It probably works both ways. As teams become more effective, people may start trusting each other more. Psychological safety may also encapsulate many of the other factors we measure, like shared learning, the quality of Sprint Retrospectives and Sprint Reviews, and so on.
But the important point is this: as teams grow larger, we can tell from our data that psychological safety declines. And given how strong the effect of psychological safety appears to be on how effective teams are, this is certainly one reason why large teams are not preferable to smaller teams.
Practical Implications And Tips
So what does all this mean in practice?
- If you compose new teams, a maximum of 10 members seems to be a good evidence-based guideline. This is supported both by our data and relevant scientific studies. Beyond that, you are likely to see process loss, fragmentation, and lower effectiveness.
- There is no hard rule for the minimum number of members. However, smaller teams seem to do better, so we would recommend aiming for the smallest number of members while still retaining all the necessary skills to deliver a “Done”-increment, as well as sufficient diversity in perspectives and knowledge. A number between 3 and 6 seems like a good range, with some margin to add more members (up to 10) if it's really necessary.
- If your team size is beyond 10 members, it doesn’t automatically mean that all will be bad. Our recommendations are generalizations. However, we would recommend looking for signs of fragmentation, diffusion of responsibility, and loss of productivity in large teams.
- One way to break up large teams is to create a skill matrix. Many teams are large because of high skill-specialization. Product development requires many different skills (analysis, UX, UI, coding, testing, support, architecture, etc). If each of those skills is centralized in one member of a team, teams quickly grow large. In this case, you want to invest in cross-functionality through cross-skill training. For example, I’m primarily a developer, but I’ve learned to do basic UX and design to offload our designer. Most importantly; the decision to break up a team and how to break up a team should always rest with the team itself.
- You can use the Scrum Team Survey to diagnose your Scrum or Agile team for free. We also give you tons of evidence-based feedback. The DIY Workshop: Diagnose Your Scrum Teams With The Scrum Team Survey is a great starting point.
- Our Do-It-Yourself Workshops are a great way to start improving without the need for external facilitators. The DIY Workshop: Use Proven Success Factors From The Past, To Improve Your Team In The Present or DIY Workshop: Build Psychological Safety With Appreciative Interviews are great starting points. Find many more here.
- We offer a number of physical kits that are designed to make teams more effective. We have the Scrum Team Starter Kit, the Unleash Scrum In Your Organization Kit, and the Zombie Scrum First Aid Kit. Each comes with creative exercises that we developed in our work with Scrum and Agile teams.
Conclusions
The question about the optimal team size is one that frequently surfaces in conversations, workshops, training, and our coaching engagements. The Scrum Guide recommends no more than 10 members. And as our data and scientific studies, this is a good evidence-based recommendation. As teams grow larger, their integration, cohesion, and psychological safety tend to break down and harm their performance. This is of course a generalization, and exceptions are possible.
At the same time, teams should not become too small. The benefit of teams is that they allow people to pool their skills and perspectives, and become more than their parts. So ideally, teams are as small as possible while still retaining all the skills they need to deliver a done increment every Sprint. If the number of members exceeds 10, you do well to invest in skill training and find creative ways to break-down teams in order to become more effective.
Good luck!
This post took 23 hours to research and write. If you think our content is valuable, and you think we should write more of it, you can support us on Patreon. Find more evidence-based posts here.
References
Dennis, A. R., & Valacich, J. S. (1994). Group, sub-group, and nominal group idea generation: New rules for a new media?. Journal of Management, 20(4), 723–736.
Duhigg, C. (2016). What Google learned from its quest to build the perfect team. The New York Times Magazine, 26(2016), 2016.
Dreesen, T., Hennel, P., Rosenkranz, C., & Kude, T. (2021, January). “The Second Vice is Lying, the First is Running into Debt.” Antecedents and Mitigating Practices of Social Debt: An Exploratory Study in Distributed Software Development Teams. In Proceedings of the 54th Hawaii International Conference on System Sciences (p. 6826).
Edmondson, A. C., & Lei, Z. (2014). Psychological safety: The history, renaissance, and future of an interpersonal construct. Annual review of organizational psychology and organizational behavior, 1(1), 23–43.
Edmondson, A. (1999). Psychological safety and learning behavior in work teams. Administrative science quarterly, 44(2), 350–383.
Horwitz, S. K. (2005). The compositional impact of team diversity on performance: Theoretical considerations. Human resource development review, 4(2), 219–245.
Moe, N. B., Dingsøyr, T., & Dybå, T. (2010). A teamwork model for understanding an agile team: A case study of a Scrum project. Information and software technology, 52(5), 480–491.
ISBSG, 2007. Team Size Impacts Special Report, Technical Report. International Software Benchmarking Standards Group (ISBSG)
