Scrum team size - Optimal vs allowed

Perhaps the suggestion is that if there are less than 3 or more than 9 Development Team members, then team size is likely to prove restricting. Evidence is likely to show that concerns such as product delivery or team co-ordination are suboptimal.

If that is indeed the case upon inspection, then the team will need to adapt accordingly. Failure to do so would mean that the team was not implementing Scrum.

The Development Team Size from Scrum Guide is a best practice, there is no definitive words like is, will, shall, should, must, etc.

It is an empirical observation that smaller than 3 would result in smaller productivity gains and having more than nine members requires too much coordination and generate too much complexity for an empirical process to be useful

so you are not breaking Scrum rules if you allow 10 or 11 without breaking them if it makes sense to keep them intact. But a line should be drawn when you find a 35 or 40 member team trying to plan and align their work every day !

so you are not breaking Scrum rules if you allow 10 or 11 without breaking them if it makes sense to keep them intact. But a line should be drawn when you find a 35 or 40 member team trying to plan and align their work every day !

Scrum guide's suggestion of keeping team size between 3 to 9 is based on lots of research. Empiricism is bound to show these problems as part of inspection (daily scrum or retrospective) in form of Scrum events taking longer time or team beginning to have virtual subteams or sub-groups.

As Ian rightly mentioned, team will need to adapt accordingly which in most cases is to split the team. Failure to do so would mean that the team was not implementing Scrum.

 Shrikant Vashishtha, the Scrum guide never mandates the limits for the team size (Example: team size SHOULD be at least three and no more than nine) but explains the challenges of teams smaller than three members (decreased interaction and results in smaller productivity gains) and teams larger than nine members (requires too much coordination and generates too much complexity). My answer is proposing it to be a best practice and principle based rather than a binding rule. I myself always suggest for teams larger than 9 members to separate themselves into two smaller teams.

If a team of more than 9 members does not increase complexity or require a lot of coordination, it might even be a sign that they aren't really working as a single team at all.

If a team of more than 9 members does not increase complexity or require a lot of coordination, it might even be a sign that they aren't really working as a single team at all.

That is a good remark, they might be avoiding each other, which can be seen as a team conflict status.