Exceeding Scrum Team Size

Last post 07:01 pm August 16, 2021
by michi smith
7 replies
03:12 pm August 2, 2021

Hello All,

Just one query:
How Scrum team size affecting the team if we exceed max limit 9 or 10?

Any technical/logical reason behind it?


03:59 pm August 2, 2021
04:51 pm August 2, 2021

The "10 person limit" isn't a hard limit:

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. If Scrum Teams become too large, they should consider reorganizing into multiple cohesive Scrum Teams, each focused on the same product. Therefore, they should share the same Product Goal, Product Backlog, and Product Owner.

Ian mentions a good point: as the team size grows, so do the number of distinct communication paths. The number of communication paths in a group is (n * (n - 1)) / 2. It's just harder for larger teams to communicate and understand what is going on within the team. Keeping the team small helps keep the communication focused and promotes more effective discussion and decision-making.

Closer to the context of Scrum, I'd consider the different timeboxes: 8 hours for Sprint Planning, 15 minutes for the Daily Scrum, 4 hours for the Sprint Review, and 3 hours for the Sprint Retrospective. I'm especially looking at the Daily Scrum and the Sprint Review where larger teams may have trouble keeping the event within the timebox simply because there are more people involved and participating. In order to keep the events focused on their objectives and finishing within the timebox, smaller teams are better.

A team of more than 10 may be perfectly fine but may start running into issues with communication and sticking to timeboxes. That doesn't mean that a team of 11 or more must be split, though. It means that you should just be paying attention to how the team is working and looking for ways to continue to optimize it, including considering splitting the team.

02:35 am August 4, 2021

My current team consisted of 15 members; 60% of the team having less thn 2 years IT experience. I found that the defect density inthe team was increasing and the productivity per team member was decreasing. we found that the a single scrum master is not able to resolve impediments for so many . also given the large number of  junior resources, they did need guidance from senior resources who themselves were busy with user stories. so we broke the scrum into 2 teams and equal distribution of senior and junior members. after 2 sprint we are seeing encouraging results on defect density

08:46 am August 4, 2021

the productivity per team member was decreasing. we found that the a single scrum master is not able to resolve impediments for so many

What kind of impediments was this Scrum Master solving? Just curious.

Was the team by any chance working on different projects?

02:20 pm August 4, 2021

The jumbo team was working on the same project. but when multiple  junior developers face  technical, environment challenges, then they dont get the scrum master's ear to share the concern as he is busy fighting some other fire. the Juniors found it difficult to navigate to the right senior developer to get their problems resolved. so we realised that it is bette to have multiple scrum teams and scrum masters to divide and conquer

11:10 am August 5, 2021

thanks all for the feedback, appreciate it!

02:05 pm August 16, 2021

Thanks for the discussion!