People ask me all the time, "What size is optimal for a Scrum team? Is there a recommended agile team size? We all know that Scrum recommends small, cross-functional teams but why is small better? And what exactly does it mean to be small?"
In my book Succeeding with Agile, I write about the many advantages of small teams:
- Less social loafing
- More constructive interaction
- Less time spent coordinating effort
- No one can fade into the background
- More satisfying for members
- Over-specialization is less likely
I also mention that I subscribe to Amazon's "two-pizza" team-size rule. That is, keep teams small enough so that they can be fed with two pizzas.
The following video goes into detail on the team size I recommend, my research into team size, and the advantages of small teams. If you'd prefer to read rather than watch, a transcript of the video is included below.
Find Your "Just Right" Team Size
There is clearly a Goldilocks size for high-performing agile teams–not too big, not too small. But how many people is that? It’s fewer than you may think.
For most agile projects the optimal team size will be 4 or 5 people, but there are times when you may want a larger team. How you decide between a small team and a larger but less productive team depends largely on whether you need the project done as quickly as possible.
Think about the movie Apollo 13, which tells the true story of the mission control ground crew who are trying to save the lives of 3 astronauts. The astronauts face a severe risk of running out of oxygen. On a project like that, finding a solution quickly is more important than doing so with the least number of person hours. And so you’d want a large team even if each person is a little less productive.
Much more often, we’re on projects on which we can sacrifice a bit of time to value in favor of the cost savings of a more efficient team. Let’s look at some research as well as some common sense about why I say a team of 4 to 5 is best.
Research on Ideal Agile Team Size
Let’s start with the research, beginning with a study undertaken by Harvard professor Richard Hackman and colleague Neil Vidmar. They assigned tasks to teams of various sizes and then asked everyone two questions:
- Was the team too small to achieve the best result, and
- Was the team too large to achieve the best result
Charting the answers they received to these two questions revealed the optimal team size. This first line shows how people responded to the question about the team being too large. Almost no one thought a team of 2 people was too large, but then the line rises dramatically, especially above 5 team members.
Conversely, regarding the line showing responses to the question about the team being too small, many participants felt a team of 2 was too small. But very few thought a team of 7 was too small.
Where these two lines intersect is what the researchers considered the optimal team size: 4.6 people.
Founded by Larry Putman in 1978, the company QSM has built one of the largest databases of metrics from software projects of all sizes and methodologies. Kate Armel of QSM studied over 1,000 projects in their database.
To test the idea of 4.6 being a good team size, Armel divided the projects into those with 4 or fewer team members and those with 5 or more. The larger teams did finish in slightly shorter time frames. But, depending on the size of the project, she found large teams were 3 or 4 times more expensive with 2 to 3 times more defects.
Advantages of Small Teams
OK, so there’s some research showing that teams of 4 to 5 are the most productive. Does this team size fit with common sense? I think it does.
Teams of 4 to 5 are far smaller than the Scrum Guide advice of “fewer than 10,” which could be 12 if the Scrum Master and product owner are counted separately. I’m not aware of any studies that show 10 to 12 being a good team size. However, the Scrum Guide doesn’t recommend teams that large, it simply defines 10 as a typical upper limit. That’s bigger than I’d recommend, but it’s OK.
A common approach to thinking about team size is to consider the number of communication paths within teams of different sizes. On a 5-person team there are 10 communication paths as each person can (and should) communicate with each other person.
That means a 6-person team will have 15 communication paths, and a 7-person team will have 21. The formula for this is the product of n times n-1 divided by two where n is the number of people on the team. Clearly, as team size grows, the overhead of all this communication can really impair agile teamwork and productivity.
Larger teams also suffer from what has become known as social loafing, which was first observed in research in 1913. Social loafing refers to individuals putting in less effort when their work will be judged as part of a group. If you were ever assigned a group project back in school, you probably experienced social loafing: You, or your teammates, put less effort into the group project than you would have into a solo project.
I think about long ago helping a friend move into his new house. There was a group of us helping and so I put in less effort than if I’d been doing it alone. Because the little bit longer it took to move everything wasn’t directly observable as my own fault, I took it a bit easy.
Ivan Steiner created a formula that accounts for social loafing, communication overhead, and any number of other factors on team's performance. He said that actual productivity is equal to a team’s potential productivity minus losses due to faulty processes.
Losses due to faulty processes are anything that prevent a team from performing at its theoretical best. In addition to communication overhead and social loafing, low morale or a lack of motivation could reduce actual productivity. So could burnout, lack of clarity, or many other things. Steiner’s formula says a team will never perform at its theoretical maximum productivity.
What Size Team Do You Prefer?
Does the idea of teams with 4 to 5 members pass the sniff test? Does it make sense with your experience? It does with mine. Small teams sure seem faster to me, and we’ve seen some reasons just now to believe that’s true. We also took a look at some research indicating the same.
