From the Scrum Guide: 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.
So, around 10 people is the maximum team size. What is not really emphasized however is that beyond this ideal size, Scrum starts to break down. It is not possible to operate in an empirical, i.e. Agile, way with teams much larger than this. Large teams means large sprint backlogs, which means more backlog refinement, more complexity and more complicated sprint plans. Artifact transparency becomes seriously eroded making it impossible to Inspect and Adapt in a meaningful way. Low transparency means superficial inspection which impedes a team’s ability to adapt effectively in pursuit of sprint goals. Teams cannot inspect their progress in a 15-minute stand-up. It is simply not possible to form a coherent picture of progress with a scrum board stuffed with 50-plus stories. The team lurches from sprint to sprint, never really knowing where they are, and continuously carrying over unfinished work.
The Scrum Guide does recommend a solution: 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.
Here they quietly and succinctly suggest the outline for a scaling framework. I discuss this in some detail in a previous post. (Written before my most recent reading of the Guide). Here is how I visualize this particular framework.
This is one of two basic patterns for scaling scrum teams – one backlog managed by a single Product Owner. Scaling requires more governance overhead for planning and synchronization, but this pattern is the simplest. A single Product Owner however can only support a handful of teams and at some point we will need to consider other models. Much commercial software development requires multiple teams to service large backlogs in acceptable timeframes. In this situation large teams must be redesigned into smaller teams so they can continue to operate with agility.