Dunbar number: Logic behind team size in Scrum / Agile

Ever wondered why individual team sizes are recommended to be between 5 to 9 members? You find this recommendation especially in Scrum, SAFe and other Agile methodologies

It goes back to Dunbar’s number

“Huh, what’s Dunbar’s number?”

Robin Dunbar an Anthropologist in his research found that there is a limit to the number of people one can have some kind of an ‘historical relationship’ and this number was around 150

This has been observed from the community sizes in hunter gatherers to neolithic village sizes to modern day active social media contacts


His study further showed that, one can have a close relationship with a group of 5 people, share a level of deep trust with around 15, have a meaningful relationship with around 50 and an active contact, where they stay in touch at least once a year, with about 150 people

Fun fact: In his study he found that those who weren’t in a romantic relationship had a close relationship with 5 people and those who were in a romantic relationship had a close relationship with 4 i.e. cost of a romantic relationship is one friend!

Translation to modern corporate teams

“So how does this relate to modern corporate teams?”

The definition of team here, is a group of individuals who have shared goals. So in Scrum / Agile, the team size is recommended to be between 5 – 9 members, so that there is a shared trust among the team members and this shared trust is built through time, therefore the teams also need to be long lived teams

As a group or department or tribe, it is advised to be within 50 members, so that they can have meaningful relationship i.e. they fall under the domain / sub-domain and can understand the challenges & help each other out

As a division, the limit is 150. In SAFe too, the number of people under the Agile Release Train (ART) is advised to be under 150

Why not a higher number?

While we understand that historically we have seen segregation along Dunbar’s number, why not increase it, after all haven’t we advanced as a species?

The rate limiter here is our cognitive ability!

Cognitive ability is the ability to reason, solve problems and comprehend complex ideas

As the team size increases, the cognitive load for the team increases and communication suffers, thereby breaking down the very benefit of a large team. The sweet spot seems to be with team sizes of 5 – 12 members

What is the takeaway?

The key takeaway is, the team size suggested in Agile / Scrum / SAFe weren’t pulled out of thin air. They are from researches which have proved that as individuals & groups, we do have scientific limitations

While Dunbar’s number is one aspect to consider, team formation also needs other considerations such as Conway’s law. Now that is a topic for another blog

If you liked this article, do comment and share. If you like reading topics related to organisation structure and team interactions, you could read Team Topologies

Read related blog on how to manage team remotely

One response to “Dunbar number: Logic behind team size in Scrum / Agile”

  1. […] we just split into 20 teams of 10 members, because somewhere you’ve read about the magic Dunbar number? Huh, but we still have the same problem that we faced with the 200 engineers in one team. So this […]