Scrum Team Size; Is it 7 ± 2 or is it 3-9?

Key Takeaways otherwise known as TL:DR

1. Scrum has never used 7 ± 2 for team size recommendation.
2. It has been used by some Scrum authors without qualification or validation. More of an accepted number than based on any science.
3. Scrum has always used 3-9 as a 'recommendation' for team size, and never a requirement. (Since 2020 they now say "typically 10 or fewer people")
4. SAFe uses 7 ± 2 but incorrectly and without substantiation.
5. 7 ± 2 is the number of objects an average human can hold in short-term memory and is nothing at all to do with team size.

Scrum Team Size; Is it 7 ± 2 or is it 3-9? Has Scrum ever recommended the former??

When I did my online Scrum quiz (now ended) I did some research. I found that:?

Scrum has never said 7 ± 2. SAFe use that term, and others have too. The Scrum guides going back to V1 only suggest (highly recommend) 3-9 people. A list of all guides past and present can be found here.

7 ± 2 comes from Miller’s Law. "The Magical Number Seven, Plus or Minus Two: Some Limits on Our Capacity for Processing Information" is one of the most highly cited papers in psychology. It was published in 1956 in Psychological Review by the cognitive psychologist George A. Miller of Harvard University's Department of Psychology. It is often interpreted to argue that the number of objects an average human can hold in short-term memory is 7?±?2. This has occasionally been referred to as Miller's law.

I then was reading the new book by James Coplien

Click the book or click here to find on Amazon

where on page 81 it is stated "Though Scrum tradition recommends team sizes of seven plus or minus two, effective teams tend to be smaller. The pattern ?110 Size the Organization on page 468 (from Organizational Patterns of Agile Software Development [CH04], Section 4.2.2) recommends a membership closer to five. Our experience suggests that the best Development Teams may comprise as few as three developers."

I went to my copy of of the book referenced also by James et al, and read the section 4.4.2:

Click the book or click here to find on Amazon.

Page 104 "By default, choose about 10 people to establish critical mass in the development of large software systems and avoid adding individuals late in the game or trying to work backwards from a completion date". 10 people not the mythical 7 ± 2. Not even 3-9.

Some of that advice is sound if you are familiar with Brook's Law.?"adding manpower to a late software project makes it later". It was coined by Fred?Brooks?in his 1975 book The Mythical Man-Month. Adding people later slows you down due to team formation overhead, skilling, context and other tasks, as well as communication pathways and hierarchies (Conway's Law) that are not directly creating value.

It continues on page 105 "Experts vary on the exact number. The number 10 has a bit of a tradition associated with it, but the numbers like 6 or 7 are also common. A two-person group is too small, and a 13 person group is too big". Still no 7 ± 2 or 3-9.

"Starting a project with 10 people can be overkill, but it avoids the expense and over-head of adding more people later. However, once a core team establishes an identity, it can grow graciously by 'Phasing it In'.

Phasing it In is another pattern that states "Phase the hiring program. Start by hiring people to meet the core basic competencies of the business and gradually bring on new people as the project needs to grow". While this makes sense it is slightly contradictory to the earlier text.

The other aspect of this whole section through to section 4:2:5 and related team size discussions is they are all based around how many thousands of lines of code KSLOC (Definition.?KSLOC. Kilo Source Lines of Code.?KSLOC. Thousands of Source Lines of Code (software)) they can deliver. This is an outdated and outmoded metric now as clean code patterns and modern development techniques are focused on limiting lines of code, and not using that as a measure of value or quality. We are no longer writing BASIC or COBOL and measuring line numbers. Yes I remember those days as a programmer.

My purpose is writing this was to highlight that the team size notion is speculative at best on the metric 7 ± 2 and I've been unable to find any peer reviewed or learned texts that support this as a team size measure. I think at best it is urban myth, and has evolved from those in the field who tried things out, then wrote methodologies or books and used that measurement. It may be supported by some anecdotal evidence, but without solid scientific research and peer reviewed papers (not the type companies write to sell their brand) then it is just that, anecdotal and unsupported by science.

The 3-9 debate is of course still open, but the Scrum guide while strongly suggesting it does not mandate it.

I tagged James Coplien in the post as he has written two agile patterns books now, and team size is a critical complement of Organization Design, so I am hoping he can add to this understanding.

?