authors are vetted experts in their fields and write on topics in which they have demonstrated experience. All of our content is peer reviewed and validated by Toptal experts in the same field.
Vytas is a professional project and product manager leading products and projects in education, 3D graphics, eCommerce, and adtech.
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:
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.
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.
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:
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.
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.
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.
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.
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.
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 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:
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.
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.
For a product manager, multiple teams mean more work tracking the progress and responding to queries.
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.
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.
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.
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.
As your team grows, you are likely to start noticing some signs that it is becoming too big, especially in:
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:
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:
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.
According to the Scrum Guide, the development team should be between three and nine people and should have all the skills necessary to deliver product increments. The number of developers is usually dictated by the needs of the product and usually is between two and five developers in a scrum team.
A scrum team is cross-functional and it includes all the people needed to deliver a product increment. Most scrum teams will have a dedicated product owner and scrum master. The rest of the team can include developers, designers, testers, or analysts.
A good scrum team is cross-functional with all the skills necessary to create a product increment. It should include developers, designers, testers, analysts, etc.
The Scrum Guide recommends having three to nine team members in a single team.
World-class articles, delivered weekly.
World-class articles, delivered weekly.
Join the Toptal® community.