Optimizing Scrum Team Size

Building efficient software teams is crucial for any organization. When forming teams, or evaluating already-existing teams, it’s important to consider the size of the team. A team too large could mean that there are too many people for each member to keep up with — a loss of information could occur and the team’s interpersonal relationships can suffer when there are too many of those relationships to maintain. However, a team that’s too small can also cause issues. This could mean there’s a skill gap in the team that makes it harder to complete projects or a lack of diversity of thought since there are fewer people with different backgrounds and experience on the team. So what is the optimal team size, and how do you achieve it?

Optimal Team Size

Unfortunately, there’s no magic number here. It’s a topic that’s been widely debated, even as far back as 1975 in Fred Brooks’s book The Mythical Man Month. Brooks argued that adding more developers to a late project will only make it later. His reasoning was simple:

1. Adding more developers means more people need to get up to speed — which takes existing developers off of their current work so they can ramp up the new members. New members may also introduce new bugs, causing it to take even more time.
2. Tasks can’t always be cleanly divided up between developers. Brooks illustrates this principle with a simple example: “The bearing of a child takes nine months, no matter how many women are assigned.” For a task that takes one person, adding more people to it will not mean it takes less time to complete.
3. More team members mean more overhead — every team member added is another person that every other member needs to communicate with and relay information to. The number of connections between team members can be revealed with a formula: N(N — 1)/2. The higher the number of team members (N), the more connections each member has to deal with. Having to foster too many relationships on a team not only takes time but also introduces more pathways for conflict.

In addition to this, we can look at the Scrum Guide. This suggests that a team of less than three is too small and a team of more than nine is too big. The reasoning is simple — a team of less than three may encounter “skill constraints”, resulting in a delayed product. A team of larger than nine results in too much overhead and coordination, as Brooks suggested.

Is My Team The Right Size?

A number of issues may indicate that your team size is off. As we noted before, a larger team can make it hard for developers to keep up with each other. Having to keep up with too many people, in addition to one’s own work, can cause confusion on a team and result in a loss of efficiency and poor coordination. If the team is too small, you may have a gap in skills that needs to be filled, or you might suffer from too few viewpoints guiding the product.

Daily Scrum

The Scrum Guide defines daily scrum, or standup, as “15-minute time-boxed event for the Development Team”. Generally, daily scrum is when the team gets together to talk about what they’re working on throughout the day. But the key here is the 15-minute time allotment. If standup takes a team more than 15 minutes, that could indicate that the team is too large. As Fred Brooks suggested, keeping up with too many team members is difficult and standup is a great place to see if developers are struggling. If it seems like the team is having trouble keeping track of what everyone is working on, that could tell you that the team is too big.

On the other hand, watch to see if your team is struggling with parts of the project. Does it seem like they’re lacking some of the skills necessary to complete it on time? If this is the case, the team may be too small. Try to be in tune with each team member’s skill sets and consider if you need to hire to fill in a gap. Additionally, if the team is too small, scrum may end up being more overhead than it’s worth — so try to measure if your team is getting any value out of the meetings at all. If you find there are certain skills you do need to hire for, freelancers can be a good option. Using Celerative can help you find the right talent you need quickly, so you don’t have to worry about the overhead of hiring a full-time employee.

Sprint Planning and Retro

Two sources of potential conflict on a team are the sprint planning and retrospective meetings. Sprint planning is where teams sit down and figure out what work they can accomplish in the next sprint, whether that be a 2-week or a month-long sprint. Retrospective is where the past sprint is reviewed and plans are made for team improvement.

Because more team members mean more potential points of conflict, sprint planning and retro can be a pain with too many team members. It’s a delicate balance — while the team doesn’t need to agree all of the time, they need to be able to find common ground. There could be a number of reasons that the planning meetings and retros aren’t working well, but if you find that it’s becoming harder for the team to reach agreements, it may be a sign the team is too big.

On the other hand, you do want a wide range of backgrounds and skills to shine through in these meetings. Research has shown that diverse teams make better decisions — too small of a team could mean that you aren’t getting a good range of perspectives, which can limit the success of the resulting product. If you feel that these meetings show a limited range of ideas and perspectives, it could be time to hire new members.

Should You Split A Large Team? How?

This question will again ask you to analyze the specific skills of each team member and how they fit into the overall project. You also need to assess if the number of current team members makes keeping track of each other too complicated.
But, let’s say you decide the team is too large and needs to split. Thinking about all of the variables to consider, it can get complicated. If you have a large team that also has one product manager and a designer, you need to consider how they will tackle working with multiple teams instead of one big one. Additionally, you have to figure out the makeup of the teams — what combination of skills and communication styles will match each other?

Making New Teams

It’s important to be in tune with your team and how they interact if you’re going to split them up. Putting someone on a team of people they generally don’t like or don’t work well with might result in that developer feeling isolated and unhappy. Thus, it’s a good idea to get input from the team itself on how they might divide themselves up. Go over the responsibilities of each team and try to learn what projects each member might be interested in, what matches their skills best, and who they work the best with.

Once the team is split, check-in on them regularly. You can utilize scrum’s guiding principles to help measure the progress and impact of the split. For example, you can implement a scrum of scrums meeting where each team picks an ambassador to represent them and relay their teams progress and pain points to other teams. Here, you can figure out if the team split is working and, if not, learn how to address the issues that come up. Of course, daily standup, sprint planning, and retro can give you clues as to whether or not the new teams are working.

Non-Developer Team Members

When you split a team, what happens to non-developer team members such as the product manager, designer, or QA engineer? This really will depend on the project and teams themselves. It’s definitely possible for these roles to work across multiple teams, but you’ll have to talk to these individuals and figure out what the workload would be like for them. Can they work effectively across teams? How many teams are they expected to manage? Answering these questions will be specific to your organization and product, so be sure to talk it out with everyone and figure out what would work best.

If you do decide to not hire additional team members, remember that now there will be a standup, planning session, and retro for each team. So product managers and other non-developer roles will have to determine if they go to all of the meetings for each team, or let developers direct themselves and drop in occasionally.

The most important thing to remember is to be flexible and patient. If things aren’t working out immediately, it doesn’t mean splitting the team was a bad idea — it just might mean you need to evaluate what isn’t working and adjust.

Conclusion

When building teams or evaluating your current teams, it’s important to factor in not just the work they do but the relationships they have to keep. More members on a team means more relationships to navigate and the chances of conflict increase. But a team too small, and it may be too homogenous and not have too many alternative viewpoints. Additionally, you may be missing crucial skills needed to build a great product.

Whether you decide to hire more developers or split current teams, it’s important to also remember how these decisions affect non-developer roles. Product managers, designers, QA, and other roles may have to manage more teams if you don’t hire for these roles for each team, so be sure to stay in tune with their workloads and how they feel about the changes.

In the end, patience is critical. It can take time for people to adjust to big changes, and it’s important to quickly figure out any pain points and address them quickly. There’s no magic number that means a team will be most effective — so finding what works can be a matter of trial and error. But once you figure it out, your teams will be more efficient than ever.

this article was written by Pablo Baldomá Jones at Celerative Blog