Skip to main content

Due to the Russian invasion of Ukraine, we have paused all purchases and training in and from Russia.

Development Team Size

Last post 05:28 am April 15, 2022 by Martin Jungmair
15 replies
11:26 am February 21, 2014

Scrum guide recommends that dev. team size should be between 3 and 9. I took that for granted since scrum guide says it and it stated that this is based on research. Now, I had someone interested in that research
Could someone point me where I can find such research?

Greatly appreciated.
Fariz Saracevic

03:29 am February 22, 2014

In 2003 Jeff Sutherland recommended constraining teams to less than 7 members:…

This has crept upwards a bit, and the maximum is now variously quoted as being 7 (Scrum Primer) or 9 (Scrum Guide).

Jeff cited the following research:

Rubin, Howard (Ed.) A Metrics View of Software Engineering Performance Across Industries. IT Metrics Strategies V:9:3, September 1999.

06:55 am February 22, 2014

Hi Ian,

Thanks for pointing to the Jeff's recommendation. This helps from general perspective but I am still looking on what bases Scrum Guide says it is 3 to 9. Number has slightly increased and I am sure there are some data to support this.

I guess, Scrum Guide authors should chime on this one and help community with some research data why they decided to increase team size.

10:32 am February 22, 2014

The number hasn't increased as it used to be 7± 2. Now it is 6 ± 3. So the max is still 9, but the range was increased in the Scrum Guide as there are plenty of successful Scrum development teams with 3 or 4 members.
The original 7 ± 2 came from a psychology paper called "The Magical Number Seven, Plus or Minus Two: Some Limits on Our Capacity for Processing Information" where it demonstrates that there are limits to how much information we can keep in our heads. In Scrum teams, as in other teams that work in complex environments (Marines, Navy Seals, Sports), keeping high bandwidth communication and relationships is essential. This becomes more difficult once we pass that magical number of '9'.

More information about that paper here:,_Plus_or_Minus_Two

Hope that helps!


11:32 am February 22, 2014

In "Succeding with Agile", Mike Cohn wrote a full chapter (10) about team structure. He quotes some research inside his writing.
He push the idea of "2 pizzas teams" and numerous reason why big teams are not efficient.
I found it very interesting !

Hope it helps

05:07 pm February 22, 2014

This gives me enough research data points how Scrum Guide came with the dev. team size.

Thank you all for your input.

06:03 pm February 22, 2014

Incidentally the two pizza team rule originated with Jeff Bezos on the principle that "communication is terrible". The next time you hear someone say "we need to communicate more in this organization", it's worth bearing this in mind. Such statements should not be considered equivalent to an appeal for "individuals and interactions". Chances are it's the dependencies between teams that are the problem, not insufficiently complex lines of communication.

05:06 am September 27, 2016

Posted By Don McGreal on 22 Feb 2014 10:32 AM
The original 7 ± 2 came from a psychology paper called "The Magical Number Seven, Plus or Minus Two: Some Limits on Our Capacity for Processing Information"
Hope that helps!

It does help in spreading the common misconception about a "magical" number 7.
Please read the paper you refer to, see… and/or do some additional googling.


10:05 am March 27, 2017


I'm new in scrum world (about one year). I have a question. What should Scrum Master do when Product owner came to him and ask for team 15 engineer? I know that this team is not scrum, but he want to work in scrum with them.



08:22 pm March 27, 2017

Empiricism asserts that knowledge comes from experience and making decisions based on what is known.


Having more than nine members requires too much coordination. Large Development Teams generate too much complexity for an empirical process to manage

The Scrum guide cites those issues with being present in teams over 9 members.  These are concerns, not failing points, and a Scrum team of more than 15 members can work.  However it won't be as effective as an appropriately sized team.  Ideally you'd separate them out into two teams, and follow the Nexus Guide for scaling Scrum out to multiple teams.  That is the method for scaling Scrum.  You could also look into SAFe, as a second method for agile scaling.

The biggest problem you'll find likely isn't the labor, but the events.  Keeping a Daily Scrum time boxed to 15 minutes can be challenging with 7 people, and doubling that team size makes it much harder.  Expanding the time box is a no-go (after 15 minutes, you start to lose the benefits of a "stand up" meeting), and you're going to have to better prepare for the other events by clarifying things in advance.

As I understand it, your job as a Scrum Master in this scenario gets harder, but not impossible.  You can have a 15-man Scrum Team, but since the events are based on the sprint length and not the team size, you'll find yourself less in the servant role and more in the leader role.  You need to put extra focus into making sure things are done efficiently, because you have less room (and less time) in your schedule as a margin of error.  Someone going off on a tangent is going to have a deeper impact on a large team than a small one.

08:22 pm March 27, 2017

No edit button.  Just clarifying that response was towards Filip.

01:27 pm March 28, 2017

Jason Jafarian thx! Your post gave me answer for my problem.

04:48 pm June 17, 2021

Scrum guide now says "typically 10 or fewer people". So Scrum Master and Product owner means "typically 8 or fewer developers" is that the generally accepted answer. Online quizzes have everything from the 3-9 to 10 developers.

What do you think?

06:07 pm April 13, 2022

What is the best way to manage waterfall projects while actively leading agile teams in a hybrid environment without coming across as a leader who does not like waterfall? 

05:11 pm April 14, 2022

What impediments does that so-called hybridisation present to agile practice? How does it compromise or inhibit the establishment of empirical process control, and the achievement of expected agile outcomes?

Establishing transparency over the situation, and what it means for those outcomes, might be a reasonable starting point.

05:28 am April 15, 2022


Think about a daily with 15 persons, that 1 minute per team member. You have then a high chance that daily is a hard reporting meeting.

Think about retro: Compared to a team with 9, everybody has 33% less talking time in average. As there are ofter talkable and calm team members, you push the calm further back.

Think about refinement / planning: coordinate 15 team members to be on the same level of ticket knowledge needs more effort. Have a look in communication therories with larger teams.

If there are two or more subteams within the team, splitting can be an option.