A lot of things about Scrum-based software development are set in stone, such as the roles involved and the kinds of meetings teams must hold. However, there are some things that can vary from project to project and company to company. One of those is team size. So, what factors influence the optimal team size, and how do you determine the right size for your project?
In the classical understanding of Scrum, there are three basic roles:
- Product Owner
- Scrum Master
- Development Team
The product owner is a “connecting link” between the development team and the client. The goal of the product owner is to guide the development team toward creating the most valuable product possible to achieve the client’s goals.
The scrum master is the servant-leader of the team. The goal of the scrum master is to help the team maximize its effectiveness by removing impediments, driving progress, educating and motivating the team, and helping the product owner.
The development team consists of the specialists who carry out the development activities on the product. According to the Scrum Guide, the development team should possess the following qualities and characteristics:
- Be self-organizing. Nobody, including the scrum master and the product owner, can tell the team how to transform the product backlog into a working product.
- Be multi-functional. Possess the necessary qualifications and experience to produce a working product.
- Be accountable. The whole team — not any individual team member — is responsible for the work result.
Optimal Team Size
The recommended size of the team is around seven members, give or take a couple depending on the nature of the project. According to the Scrum guidelines, teams of larger sizes require too much effort for communication. Teams of smaller sizes may not have sufficient qualifications or the capacity to complete work in a timely manner.
When forming a development team, it is important to consider the needs of the team, and not just random numbers. Here are some factors to consider:
- Cross functionality: The team should have the skill set to build the product.
- Availability: Ideally, each team member is working on just one project at a time.
- Stability: The members of the team spend a significant amount of time being a part of this team and must be reliable.
- Diversity of reasoning and experience: A wide array of ideas, backgrounds, beliefs, and life experiences might be useful to call into existence creativity and versatility of approaches.
- Psychological safety: The working environment within the team should be favorable so that the team members are able to share ideas.
- Equality in communication: Each team member should be able to speak their mind and be heard.
- Openness to new ideas and desire to learn.
It may be tempting to increase quality, capacity, and diversity of ideas by simply adding more people to the team. But be careful: Each member adds some productivity to the team, but each member also increases the communication load. Here, a well-known formula is applied: N (N – 1) / 2.
This formula shows how many interactions there will be within teams of various sizes. N refers to the number of people on the team. So, in a team of 5, there will be 10 interactions. This means 10 different combinations of communication among the team members. In a team of 7 members, there will be 21 interaction, and in a team of 9 members, there will be 36 interactions.
As you see, an increase in team size from 5 to 7 members almost doubles the communication load, which can have a negative impact on productivity after a certain point. When planning team size, be sure to take the communication load into account.
To avoid this pitfall, understaffing the team initially with the intent of growing it later may seem like a clever solution. But before you go that route, consider Brooks’s Law, an observation about software project management that warns, "Adding manpower to a late software project makes it later."
When new members are added, the team inevitably puts effort into bringing them up to speed, briefing them on the progress, goals, approaches, and nuances of the project. The team members invest their time into sharing knowledge and synching with the new arrival, showing how the work is organized. And all that time not spent developing the project means the work is slowed down, overall.
Brooks’s law does not mean that team should not grow, but growth does not happen fast. If there is a decision to grow, a part of productivity will be used to scale up.
In short, there is no one “right” team size for a software development project. Instead, it’s up to each product owner and scrum master to carefully weigh the needs of the project versus the abilities and temperaments of their available developers and put together the right — and right sized — team for the job.