Development Team Size

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

http://scrum.jeffsutherland.com/2003/02/scrum-keep-team-size-under-7.ht…

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.

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.

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: http://en.wikipedia.org/wiki/The_Magical_Number_Seven,_Plus_or_Minus_Two

Hope that helps!

Don

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 !

http://www.mikecohnsignatureseries.com/books/succeeding-with-agile

Hope it helps

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

Thank you all for your input.

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.

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!
...
Don

It does help in spreading the common misconception about a "magical" number 7.
Please read the paper you refer to, see http://www.centigrade.de/blog/en/article/the-number-seven-is-not-magica… and/or do some additional googling.

Thanks
-MillerTime

Hi,

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.

F.

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 Scrum.org 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.

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

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

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?

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? 

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.

@Filip

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. 

In the simulator to the question about:

What is the typical size for a Scrum Team?

(choose the best answer)

A.10 or fewer. (Correct) 

B.9.

C.7 plus or minus 2. (My - not correct)

D.Minimum of 7.

But I think 

The best answer is C. 7 plus or minus 2.

The typical size for a Scrum Team is commonly recommended to be around 7 plus or minus 2 individuals. This means that the ideal Scrum Team size ranges from 5 to 9 members.

The rationale behind this recommendation is to maintain effective communication, collaboration, and self-organization within the Scrum Team. With a smaller team, it can be easier to coordinate and make decisions efficiently. On the other hand, a larger team may encounter challenges in effective communication and coordination.

It is important to note that the specific optimal size of a Scrum Team may vary depending on the context, nature of the project, and the organization. Some teams may find success with fewer than 5 members or more than 9 members. However, the guideline of 7 plus or minus 2 is a commonly accepted range to ensure productive and cohesive teamwork in most situations.

Option A ("10 or fewer") is a reasonable approximation of the recommended team size range.

Option B ("9") falls within the recommended range of 7 plus or minus 2.

Option D ("Minimum of 7") is not accurate as there is no minimum requirement for the Scrum Team size. The emphasis is on the ideal range of 7 plus or minus 2, rather than a specific minimum or maximum number.

The typical size for a Scrum Team is commonly recommended to be around 7 plus or minus 2 individuals. This means that the ideal Scrum Team size ranges from 5 to 9 members.

The Scrum Guide changed the number in November 2020. It now states: 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.