If Scrum Teams Become Too Large, They Should…

What To Do When Teams Grow In Size

Scrum is built around the idea of small, self-managing teams that can move quickly, communicate effectively, and deliver value consistently. But what happens when your Scrum team starts to grow? When you add more people, more specialties, and suddenly find things starting to slow down?

It’s a common scenario—especially in growing organizations—and it often leads to a key question we hear in training sessions and coaching engagements: “How big is too big for a Scrum team?” More importantly, if Scrum teams become too large, what should they do?

What the Scrum Guide Says

Let’s go right to the source: the Scrum Guide. It offers a clear and specific recommendation:

“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.”

That last line is critical:
“If Scrum teams become too large, they should consider reorganizing…” Not into completely separate units with different goals—but into smaller Scrum Teams that are still working on the same product, with the same Product Goal, Product Backlog, and Product Owner.

Team Size Isn’t Just About Numbers

While the Scrum Guide gives us a number—10 or fewer—it’s not about arbitrary limits. Instead, the key is team effectiveness.

“If your team is struggling to deliver a Done increment every Sprint, communication is breaking down, or collaboration feels chaotic, your team might be too big—even if it’s still technically under 10 people.”

Scrum Masters and Product Owners should look for signs in Sprint Reviews, Retrospectives, and Daily Scrums that indicate inefficiencies. Watch for:

• Siloed work areas
• Decreased team velocity
• Redundant communication
• Missed Sprint Goals

One of our trainers shared how a Scrum team with 12–15 members pretended to be one team but functionally acted as three distinct sub-teams. They worked in separate areas of code, never crossed over, and were essentially three independent groups attending the same Scrum events. In hindsight, they should have restructured into smaller Scrum Teams focused on the same backlog—just like the Scrum Guide recommends.

Don’t Split By Specialty

A mistake we often see is splitting teams along functional lines, such as separating out QA or UX. But Scrum defines Developers as anyone involved in delivering the product, including QA.

Segregating testers from developers results in fragmented accountability and bottlenecks. If Scrum teams become too large, they should reorganize—but not in a way that fractures cross-functional capability.

Instead, ensure each smaller Scrum Team includes all the skills necessary to produce a Done increment independently.

Can Teams Be Too Small?

Yes—and this is often the lesser-discussed issue.

We’ve seen organizations break teams into tiny units, such as three-person Scrum teams. In theory, smaller teams = more agility. In practice, these micro-teams often lack the horsepower to deliver value every Sprint.

The Scrum Guide reminds us that teams must be “large enough to complete significant work.” If they can’t do that alone, they shouldn’t be a team.

Sometimes, the solution isn’t splitting—it’s recombining. One coach likened this to forming Voltron: several small teams joining forces to become one stronger, more capable Scrum Team.

Reorganize with the Done Increment in Mind

Whether you’re splitting a large team or combining small ones, the goal is the same: every Scrum Team should be able to independently deliver a Done increment by the end of each Sprint.

If your teams are dependent on one another to ship usable software, they aren’t truly cross-functional—and that violates the spirit of Scrum. Build your teams so that each one can stand on its own and contribute fully to the shared Product Goal.

Summary: What to Do When Scrum Teams Get Too Large

To wrap up, here’s what you should remember:

• If Scrum teams become too large, they should reorganize into multiple smaller teams working toward the same Product Goal.
• Ensure each team is cross-functional, collaborative, and capable of delivering a Done increment independently.
• Don’t split by department or specialty—split by product alignment and delivery capability.
• Sometimes, the solution is merging teams, not splitting them.

Scrum is all about adapting to complexity. As your teams grow, inspect your structure, and don’t be afraid to adapt it in pursuit of greater agility.