Optimal Team Size for Agile & Scrum Teams
Are you wondering if your agile team is too big or too small, or what is the optimal team size for high performance? Chances are, your team is bigger than it could be.
BLUF: Agile and Scrum Teams with 5–6 team members are best for high performance. The Scrum Guide includes a recommended Scrum team size of between 3 and 9 members. And Amazon’s Jeff Bezos is famous for the two-pizza team rule which means that teams should be sized to consume two pizzas.
This blog describes the optimal and recommended team size for an agile or Scrum team and explores some of the considerations when forming agile teams.
What is the Recommended or Optimal Agile Team Size?
A question that I get frequently is what is the optimal agile team size? For those of you who are just looking for a quick answer, the optimal agile team is just 5 or 6 people. That is 5 or 6 team members and excludes roles like Scrum Master, Product Owner, and God forbid, Project Manager.
But a more complete answer might be that it depends. There are factors that may argue for a larger or smaller team. The recommendation of 5–6 is based on my experience with a lot of different teams. It has been my experience that people tend to err on the side of teams that are too big. That creates a lot of unnecessary overhead and each additional member adds less and less to the productivity of the team.
Let’s explore those responses and the considerations for team size. But first, let’s explore what is an agile or Scrum team.
What makes an Optimal Agile or Scrum Team?
Is it an Agile or Scrum Team?
Let’s start with what makes an agile team. Many people use the terms interchangeably and this is understandable. After all, 80% of people who use agile today use the Scrum Framework. Every Scrum team is an agile team, but the converse is not true. There are SAFe teams, Kanban teams and Extreme Programming (XP) teams that would be considered agile teams and they don’t use Scrum. There are even agile squads and guilds (see below) that are not Scrum Teams.
Whether it is good or bad, even the people who use approaches outside of Scrum tend to use the Scrum Roles of Developers, Scrum Masters, and Product Owners. They have become quasi-standard.
- The Scrum Master is a servant leader, coach, and impediment remover.
- The Product Owner is the voice of the customer — they set priorities and make decisions about what is valuable for the team to build.
- Developers are the members of the team that do the work. The term developer is a generic term that includes anyone needed to “develop” the solution.
Are You Sure It is an Agile Team?
Sometimes people ask about the size of agile teams but in fact, they aren’t actually using agile. They spend pondering how many people to put on their “agile” team which is a distraction. That time would be better spent actually learning about and applying agile ways of working. The size of the team is not as important as how they are going to operate.
There are a few questions you can ask to get a sense of whether someone has a true Agile or Scrum Team:
- Will the team be self-managing? Agile teams are self-managing (or self-organizing). That means the people closest to the work figure out how to get the work done. If you have someone outside the team managing tasks and telling the team what to do, well, that really isn’t agile.
- What Agile Approach will you use? Some 80% of people using agile today are using Scrum. Will you use the Scrum Framework as described in the Scrum Guide? Will you deliver a finished increment of the solution each Sprint? Or, instead of Scrum are you still using waterfall or some whacky hybrid? Do you have design sprints or analysis sprints, followed by a development sprint and then a test sprint? That’s not agile.
- Will your ‘Agile Team’ own the delivery of the solution? I ask this question because frequently we have a ‘team’ that is little more than a collection of individuals or a group or department. They don’t collectively own the end-to-end delivery of the solution. Instead, they are single specialty teams that hand off their work to other single specialty teams. Their efforts are scattered and they are ineffective as a team. Someone outside the team is often needed to corral them (see item 1 above). Agile team size doesn’t apply to them since they aren’t agile.
- Do you have dedicated and stable Teams? Are your agile team members dedicated to just one team or do you assign them to 2 or more teams? Though most frameworks don’t dictate that you must have dedicated teams, if you are going to assign people to 3 or 4 teams then you clearly don’t understand agile ways of working or just how ineffective that is. You can choose any team size you want — none of those will be optimal. Spreading people around only forces context-switching.
For more details on Agile, check out this post: What is Agile and Why is it Important?
What is the Best Scrum Team Size?
The 2020 Scrum Guide says this about the size of the 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. In general, we have found that smaller teams communicate better and are more productive. 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.
— Jeff Sutherland and Ken Schwaber, The Scrum Guide (2020)
For the purposes of the best scrum team size, I recommend that you focus on those people actually doing work on the team. In Scrum, that is the developers. That means ignoring leadership roles such as department leaders, managers, project managers and others who don’t actually work on team tasks. Likewise, you can ignore stakeholders, subject matter experts (SMEs), and technical experts that may occasionally help or contribute but aren’t necessarily full team members.
Some people like to use the terms “Core” and “Extended” or Pigs and Chickens to divide between those working on the team and those in more of a supporting role. I just focus on those people who are the developers on the team. Otherwise, you could go around in circles playing WhataboutHer? and WhataboutHim? When in doubt, ask the team who is doing the work. They know who is in the trenches with them.
Jeff Bezos’ 2-Pizza Rule: Why Amazon found that Two Pizza Teams are Optimal
Jeff Bezos of Amazon was famous for what he called the 2-pizza rule. He said an ideal team is one that can be fed by 2 pizzas. Though I’m pretty sure that Jeff didn’t have Chicago-style deep-dish pizzas like Lou Malnatis in mind when he came up with that rule. And to be clear, Lou Malnati’s pizza is the standard for feeding Agile Teams in Chicago.
How big is a two-pizza team? Certainly no more than 9, depending on how big of an appetite that they have.
Using the Spotify Model? How big should your Agile Squads and Guilds be?
Ok, first of all, there is no Spotify model. If you rebranded your teams to squads and tribes to be like Spotify, you may want to do some research on whether that was a good idea
If you do use Squads, my recommendation for smaller being better still applies. Five to six team members would be my recommended size for an agile squad.
Other Experts Weigh in On the Best Team Size
So I mentioned above that the Scrum Guide says 10 or fewer Scrum Team members which means 8 or fewer developers. That is in line with what I learned in the first agile training I took years ago where they said agile teams should be 7 +/- 2 people which is five to nine team members. What do other experts think?
One of the first to write about team size for technology projects was Frederick Brooks. In his classic book on software engineering, the Mythical Man Month, Brooks pointed out something that was counter-intuitive — more people on the team can actually do more harm than good:
“Adding people to a late software project is like pouring gasoline on a fire–it just makes it later.”
— Frederick P Brooks, the Mythical Man and Other Essays on Software Engineering (1974)
J Richard Hackman in his great book Leading Teams, described his work with Neil Vidmar in trying to determine the perfect size for a team. Through an informal study, Hackman and Vidmar found that the optimum number of team members is 4.6. They encouraged people to err on the side of too small rather than too large:
That conclusion, of course, was just an exercise done from a not-very-important study, but it does remind us that most of the time smaller is really better. Indeed, a team may actually perform better when it has slightly fewer members than the task actually requires.
— J Richard Hackman, Leading Teams; Setting the Stage for Great Performances (2002)
General Stanley McChrystal in his excellent book Team of Teams said this about optimal team size and his challenge to create a large team that was cohesive:
Small teams are effective in large part because they are small — people know each other intimately and have clocked hundreds of hours with each other. In large organizations most people will inevitably be strangers to one another. In fact, the very traits that make teams great can often work to prevent their coherence into a broader whole.
— General Stanley McChrystal, Team of Teams
As with many things, sometimes the answer to what is the optimal agile team size could depend on your specific context.
The Optimal Number of Agile Team Members — Some Additional Considerations
I know that I said 5 or 6 team members is my recommended agile team size. That usually works for most situations. Here are some additional considerations that you may need to factor into your optimal agile team size:
- Team Member Specialization — If you have team members that insist on sticking to their own single primary skillset (“I don’t do windows”) then you are going to need a bigger team than if the team is willing to learn new skills as needed to deliver the solution. This doesn’t mean that every team member needs to have every other skill, it means they are T-Shaped and willing to learn. You can have a smaller and more productive team if you foster learning, skill development and ownership of the Sprint Goals rather than deep specialization.
- Solution Complexity — Is your solution pretty complex? How many team members will you need to take expressed business needs and deliver a solution by the end of the sprint? As you can imagine, this is related to the first item. If you have a complex solution and team members are highly specialized, you are going to need a bigger team.
- Overall Effort & Timeline — Though this may be hard to gauge, you should consider the overall size of your effort and delivery requirements when determining team size. That doesn’t mean that you would want a team of 150 people if you have a Herculean effort, but it may push you to have multiple teams that on average are going to be bigger than they would if you had a smaller effort. Try breaking your big effort into chunks that smaller teams can deliver.
- Are You Providing a Coach? Another consideration is whether you are going to provide some sort of coach or Scrum Master for the team. If you don’t have one, the team will need to spend more of their time on impediments and facilitation than they would otherwise. So you will need a bigger team if you don’t have a Scrum Master than if you do have one.
- Team Maturity and Experience Together — Teams that have worked together and matured through the Tuckman stages of development will be more effective and suffer less from having more members than those who are not as experienced. New teams that have not performed together will spend more time thrashing. Smaller teams also tend to move more quickly from Forming to Performing.
- Adherence to the Scrum Framework — People complain a lot about the number of meetings in Scrum (see There are Too Many Meetings in Scrum). However, each Scrum Meeting is focused and has a purpose. If you adhere to the Scrum Framework, facilitate your meetings well, and avoid attending irrelevant meetings, you can afford to have a slightly larger team. Your meetings will focus on communication and collaboration and won’t be the colossal waste of time that most of the non-Scrum meetings tend to be.
Less is More — The Decreasing Utility of More Team Members
You have probably experienced the challenges of working in a large team. While big teams have the potential to get more done, those big teams also suffer from what Ivan Steiner called process losses:
- Meetings are hard to schedule
- People are less likely to jump in to help (swarm)
- Less feeling of ownership of the team’s goals and work
- Lack of transparency
- Lack of psychological safety and trust
- Reluctance to cross-train and build T-shaped skills
- Increased specialization and sub-teams (the “testing team”) within the team
- Difficulty with participatory decision making
There is also the concept of the bystander effect, which occurs when the presence of others discourages an individual from intervening. Simply put, people don’t feel compelled to act because they assume someone else will take care of it.
A recent Gallup Article described these issues with large teams:
Larger teams tend to be more difficult to lead and more frustrating to work on because members devote more time to organizing their work and less time to actually doing it.
Consider the simple act of taking turns in team conversations. The more people in a meeting, the more people who can — and often will — offer opinions, advice and questions. That slows everything down, no matter how “agile” an organization may claim to be. Misunderstandings and conflict flare because, as teams get larger, it becomes harder and harder for each member — including leaders — to track and respond to the needs of every other member.
— Robert Sutton and Ben Wigert, Gallup
So as we add more team members, each one provides less and less marginal improvement in productivity. There is a point of diminishing returns as you get up to 9 or 10 people.
It is easy to see the increasing complexity and communications overhead that comes with larger teams. Consider the diagrams below which show a comparison of the communication channels for a team with five team members and another with 10 team members. The number of interaction points with a five-person team is 10. That number jumps to a whopping 45 with a 10-person team!
Why I Recommend Five or Six Members For an Agile Team Size
Larger teams are rarely productive. In a team of nine or 10 people, you are more likely to have members gold-bricking and not working to their potential. Given a choice between one team of 10 and two teams of five, I would take the two teams of five any day. To be honest, I would be tempted to take one team of five team members over a team of 10, especially if the team of 10 includes part-time people. I’ve just seen smaller teams outperform larger teams — they punch above their weight!
That is based on my experience with teams of various sizes over the last 15 years. I’ve worked with over 125 agile teams of various sizes during that time including teams I’ve trained, coached, or both. The teams that I had supported varied quite a bit in size, from teams as small as four to teams as large as 13. I don’t think I ever worked with a team larger than 13 though I have heard stories of teams of 25 or more people. I cannot imagine how painful a Daily Scrum would be with 25 people!
When I reflect on those teams and their relative performance, I know that smaller is better. I don’t have quantitative performance data but my experience tells me that smaller teams tend to gel more quickly, are much more transparent, and tend to take ownership of results. Smaller teams tend to be more focused, move more quickly, and get more done per person. There is no room to hide out or coast on a small team.
One of the last teams I helped transition from waterfall to Scrum was just 4 team members. The “Flexstars” had high morale and esprit de corps and were well on their way to being a high-performing team. With just four team members, the Flexstars were a bit of an exception though. I would definitely strive for a team that is five or six team members.
Anthony Mersino is the founder of Vitality Chicago, an Agile Training and Coaching firm devoted to helping Teams THRIVE and Organizations TRANSFORM. He is also the author of two books, Agile Project Management, and Emotional Intelligence for Project Managers.