Too Big to Scale: Optimal Scrum Team Size Guide

Listen to the audio version of this article

Whether you are working in a small startup or on a new product in a large company, you are likely to come to a point when you have too many people in one team. Identifying the signs early on will save you from reaching the most inefficient stage of the team.

Every product is different and so are the teams working on them. Thus, splitting a team will also require you to make some decisions that reflect your circumstances. Some things to consider are:

• How to maintain know-how integrity when teammates are no longer working together
• Should you split along functions (e.g., front-end and back-end teams)?
• Should the new teams have separate backlogs?
• Should the product management team grow accordingly?

When Should You Start Creating a Second Team?

The most obvious indication to start thinking about a team split or adding a new team is when your budget increases. This may occur to a new investment round in a startup or new goals for your product in an enterprise. If the budget increase is so substantial that your team will grow 3x or more, then it’s a no-brainer that you will have to split your current team to distribute know-how. However, the decisions become not so clear cut when the budget increase is incremental and you end up adding a few new people to the roster. If, say, you have plans to grow your team from 7 to 11 people, does that require a split? Agile promotes small teams but it also promotes individuals and interactions over processes and tools. Having two or more teams inevitably creates more processes to be able to work in sync.

What Do the Experts Say?

Jeff Bezos, the founder of Amazon, has been using the two-pizza rule for both meetings and teams. That means that each should have only as many people as two pizzas can feed over lunch.

The Scrum Guide suggests a typical scrum team size having between three and nine team members who are actually executing the sprint backlog. That means you wouldn’t include the product owner or scrum master in the total unless either of them is implementing the sprint backlog items.

These numbers seem to make intuitive sense but there is also some math behind it. If you think about a team, every person is like a node and they link up to other nodes. These are the interpersonal relationships between teammates. They can be friendly, competitive, spiteful, or caring. Whatever the relationship is between two people, it still a link that requires some mental capacity from each person. As the size of Scrum team grows, these numbers of these links do not grow linearly. The formula for links between nodes is \(n(n-1)/2\). Here is the link growth chart:

The chart clearly illustrates from a mathematical standpoint why teams operate most efficiently when they are not too big. If we take the 3 to 9 team members suggested by the Scrum Guide as the average scrum team size, we end up with between 3 and 36 links. If we grew to 15 people, we would have over 100 links. A team of this could only operate efficiently if their duties were very well defined and rarely overlapped or if there were some unofficial sub-groups. Neither is the case or desired when working based on Agile principles.

Signs That the Team Is Getting Too Big

Daily Scrum

Sometimes referred to as the daily standup, the daily scrum is a get-together of the whole team to discuss progress and impediments of the sprint. The Scrum Guide suggests to time these at 15 minutes and that is a good litmus test for maximum scrum team size. If you start noticing that your team is overrunning the 15-minute bar, then it can indicate one of two things:

• The daily scrums are not efficient. People are going into too many details. Or there is no clear speaking order and it takes time for teammates to speak up. Maybe the product owner or scrum master is using the daily scrum as an opportunity to provide various updates not related to the sprint.
• The team is too big. If the daily scrums are efficient, but you are still overrunning the 15 minutes, then you might simply have too many people on the team. You should also start noticing that people are losing interest because there is a limit to how much information a person can take in. If too many people are providing updates, it becomes hard to keep track of everyone’s progress and have an understanding of the team’s status. This makes people turn inwards and reflect only on their progress rather than look out for opportunities to help out others.

Grooming and Sprint Planning

Both grooming and sprint planning are activities related to breaking down user stories and estimating their delivery time or size. While having more people can help the team arrive at better decisions, having too many people might drive the team to a deadlock. There are always different ways to accomplish the same task and the number of arguments on each side increases with the number of people in the team.

As with the daily scrum, don’t confuse an inefficient planning session with the team being too big. Ultimately, it’s the scrum master’s job to make the scrum ceremonies be efficient and effective.

Retrospective

During a retrospective, the team members can resolve any arguments or conflicts and come up with ways to improve their work process. Retrospectives teach us the art of compromise as it makes us seek common ground between different parties. A team is as powerful as its members are willing to compromise on their differences.

However, as with sprint planning, too many team members create too many links, all of which are potential points of conflict. Start noticing if you are finding less and less common ground during retrospectives. It may be a sign that the team is too big and would benefit from being split.

How to Split the Team

On its face, splitting the team is a relatively easy task. Divide team members into two groups, make sure each has similarly experienced people, and define the objectives for the new teams. However, there are quite a few things to consider which could have a big impact on the future success of the new teams.

Team Morale

Probably one of the most important things to keep in mind is team morale. At the end of the day, it’s the people in the team who will have to work in the new composition. If the team is mature in terms of Agile principles, then they should be able to make the split themselves. This is the most desirable outcome because the team members know best their internal relationships—who works best with whom and who could benefit from being in separate teams.

Cross-functional Teams

Scrum promotes cross-functional teams “with all the skills as a team necessary to create a product increment.” This holds true when scaling to two or more teams. For a lot of developers, especially if they are new to Agile, the natural tendency is to think alongside technical lines. For example, teams often want to split into the back-end and front-end teams. This might make sense in some rare occasions but as a product manager, you should advise against it most of the time. A team full of front-enders is not able to deliver a product increment on their own and will naturally start thinking more about technical capacity, which is what unites them. Instead, they should be focusing on the customer and how to satisfy their needs.

Another interesting consideration is the non-development roles in the team. In various situations, a team might include a designer, business analyst, or a QA specialist. Once you split a team, especially if you are not hiring too many new people, a dilemma arises regarding what to do with these roles. Should they split their time among the teams? Should you hire new people, who would be dedicated to one team only? Should they work with the development teams or be part of the product team?

There really is no good single advice for this because each product is so different. These decisions are best made together with the team, keeping in mind that you might need to course-correct along the way.

Should the Teams Have Separate Backlogs?

If a team is split, then the natural question is if they should be working off the same backlog or have separate ones. We can look to the Scaled Agile Framework for guidance.

Scrum@Scale

Scrum@Scale is a methodology developed by the creator of the Scrum Guide. Scrum@Scale is not very prescriptive and does not outline specifically how to handle product backlogs. It does, however, note two points:

• The team-level process is the same as laid out in the Scrum Guide.
• Product owners form a product owner team, where they create a single unified backlog. This is done to avoid duplication of work and to create visibility within the company. At the same time, teams have their separate backlogs which feed items from the unified backlog.

So in essence, Scrum@Scale images the new teams with their own respective POs and backlogs. It just adds some additional structures to coordinate the work between the teams. Scrum@Scale works best with several, tens, or hundreds of teams but it can provide some valuable insights even if you are working with two teams.

Large-Scale Scrum (LeSS)

LeSS promotes an interesting approach to the product backlog. In LeSS, a product owner works with two to eight teams. It might seem impossible for one PO to work with so many teams. LeSS philosophy is that the PO works at an abstract level and delegates the product backlog item refinement responsibilities to the teams. In this case, cross-functional development teams should also include business domain knowledge in order to be able to deliver a product increment. In LeSS, there is only one backlog.

How to Keep Up to Date

For a product manager, multiple teams mean more work tracking the progress and responding to queries.

Prioritize Meetings

If you were attending the daily scrums of a single team, continuing this habit will most likely be unproductive. Consider daily scrums as a chance to drop in to get a pulse of the teams and remind them that you are available for discussions.

Your attendance in sprint planning sessions will depend on the maturity of the teams. If the teams include a lot of fresh faces or they haven’t been working with Agile for a long time, then some guidance from your side will be necessary. Even if you feel confident in letting the team plan without your attendance, make sure to be available to drop in or voice chat with the team during their plannings if any questions arise.

Sprint reviews will have to remain your top priority and all of them should be attended. Sprint reviews are a chance to get firsthand feedback from any present stakeholders and the team itself. It’s a time when assumptions are validated and it should not be missed.

Engage More with Scrum Masters

While you might be reducing your engagement with some of the scrum ceremonies, you should double down on your partnership with the scrum master. There might be more than one now after the team split, in which case, you would need to work closely with all of them.

Make sure you can trust them to give an honest view of the team’s progress and any problems that arise during sprints. These relationships will let you stay up to date without the need to engage in all the scrum ceremonies.

Introduce Scrum of Scrums

Sometimes called a meta scrum, a scrum of scrums is a new ceremony which is typically introduced as scrum processes scale. It is a replica of the daily scrum at a higher level. Each team designates an ambassador, all of which meet at the scrum of scrums every day to discuss progress and impediments. This ceremony is also used to highlight any cross-team technical issues that might need to be resolved.

Consider Expanding the Product Team

If your scrum setup requires the product manager to engage actively with the team, consider adding more people to the product side. There are a few ways to approach this.

Junior product managers. One pathway is to take on a more strategic role for yourself while adding junior product managers to handle some of the daily chores. They could take on some tasks like quality assurance (QA), writing specifications for user stories, or creating high-level mockups for new features.

Business analysts. Another way is to have one or more business analysts work in or alongside the teams. The product manager can work with business analysts to identify product assumptions and then let business analysts find ways to validate them either through research or new features.

Conclusion

As your team grows, you are likely to start noticing some signs that it is becoming too big, especially in:

• Daily scrum. If you are overrunning the 15-minute timeframe during daily scrums and see that people start to lose interest.
• Sprint planning. If you end up in deadlocks during sprint planning more and more often.
• Retrospective. If you start noticing that it’s becoming harder to reach compromises during retrospectives.

All of these point to the fact that you might need to split the team. Splitting a team is seemingly an easy task but it also has lasting consequences and every product manager has a few things to consider when doing so:

• Team morale. Ideally, you should let the team decide how they want to split to minimize the number of scrapped good working relationships.
• Cross-functional teams. Teams should have all the skills necessary to create a product increment.
• Product backlog. Decide if your teams will have separate or a single unified backlog.

Keeping track of two or more teams will require you to prioritize. A effective product manager should plan how they will keep up to date with the new teams:

• Prioritize meetings. Think through which Agile ceremonies are worth your time and which can be ignored.
• Engage with scrum masters. Use scrum masters as your team proxies and gather information from them.
• Expand the product team. Add people to work with you and help out with either daily repetitive tasks or conduct user research and market analysis.

By utilizing these suggestions, you should be able to have a clean team split. If your teams keep growing and you will be adding even more team in the future, you should read about Scaled Agile Frameworks, which provides structure and process suggestions for Agile at scale.