Exceeding Scrum Team Size

Any technical/logical reason behind it?

Logical: n(n-1)/2

Technical: pizza × 2

See: https://buffer.com/resources/small-teams-why-startups-often-win-against-google-and-facebook-the-science-behind-why-smaller-teams-get-more-done/

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.

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

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?

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

thanks all for the feedback, appreciate it!

Thanks for the discussion! 

It's perfect if you have the human resources. I mean we have someone who undertakes the role of the new scrum master. But if not, is there the other way to split scrum team?

Lots of studies say big teams devolve into small tribes.  You can't be a slacker on a team of 6 and get away with it, but a team of 20 - easier.  Less peer to peer work and more task work on larger teams.

There's a discussion on this in the PSPO class and the PSM class.

A quick google search on team size productivity will lead to great article, like the Ringelmann effect.

Look at "team topologies" for good ideas too.  

is there the other way to split scrum team?

There's a blog written by Ken Schwaber that poses the question “What is the best way to organize 100 developers into Scrum Teams and ensure that they select the correct Product Backlog items.” It was written 10 years ago but still relevant today: https://kenschwaber.wordpress.com/2012/07/25/self-organization-and-our-belief-that-we-are-in-charge/

Yes, there are other ways to split a Scrum team, and it's important to find the approach that works best for your specific situation. The blog post by Ken Schwaber that you shared is a great resource and provides valuable insights into self-organization and team dynamics in Scrum. It's important to remember that Scrum is a flexible framework, and there are no strict rules on how to split a team. Ultimately, it's up to the team members and the organization to work together to find a structure that maximizes productivity and efficiency while also allowing for flexibility and adaptation. Thank you for sharing the blog post, and I hope that it provides helpful guidance for your team.

Best Regards 

Ritik