How to Determine the Right Size of Your Software Development Team

The word “optimization” gets thrown around a lot lately and it’s gone far beyond digital marketing. We are all trying to be highly efficient and try to approach each task in our lives in the most intelligent way possible.

The same ethos applies to creating dynamic software development teams. When we start planning on building a team, we usually start with skill sets, knowledge, and experience. But in this context, size also plays a crucial role in building the best team.

For example, if it’s a small team, the number of team members involved can play a critical role. As small teams are highly dependent on skills of each member, the project can be significantly vulnerable losing one individual.

On the other hand, large teams can be plagued with complexities when it comes to human communication. Furthermore, when you’re dealing with a large group, it can also quickly turn into a group of people with an average skill set.

As a result, you have to find a balance somewhere in the middle to build an optimum team. But the size of the team is relative to a variety of variables like the following:

Complexity of the application
How much code needs to be written
Budget constraints
Project schedule
Available talent

There is obviously no magical number in this situation although there have been a few thrown around. If you look at Scrum Community forums, you’ll see the number seven thrown around while being supported by the idea that a scrum team of nine members would be difficult to coordinate.

While some people may have had a difficult experience with a team of more than seven members, it doesn’t mean that a team of 14 wouldn’t work. But to be effective, you have to carefully manage the numbers in relation to the requirements of the project.

So how do you go about determining the right size for your software development team?

Do Some Capacity Planning

You can start by doing some capacity planning to make sure that everyone on your team has enough work for the duration of the development process. This approach makes sense and is one of the pillars of the agile software development methodology.

By following this method, you can also get your team to commit to a story point for any given iteration and mark it when they have completed a task within a stipulated time. But what’s important to note here is that poor estimations of story sizes and capacity planning will lead to major failure.

But to get to the capacity planning right, you will also have to estimate how many people will be needed to complete the project within the number of productive hours that are available.

This can get a little tricky, to say the least. So how do you figure this out?

Identify Key Members of Your Team

Managers usually look at individuals in a team as either a specialist (an individual with unique knowledge that relates to a particular task) or a generalist (an individual who is highly versatile with extensive knowledge on a variety of interdisciplinary tasks). Sometimes they also seek out individuals with a mixture of both.

There’s a feeling that generalists would be more agile and that would be an asset to meet the needs of the project. Furthermore, the rebalancing of work with generalists in the team won’t have any impact on the throughput of the whole process.

When teams are unable to rebalance the workload, they are usually made up of specialists. So getting this mix of specialists and generalists right will be critical moving forward. In fact, it will play a vital role in the successful completion of the project.

You also have to calculate the hours needed by each team member to complete the project. You can do it by using the following formula:

The number of days in the development cycle x the size of the software development team x available hours (ex: 8 hours per day) = Project hours

But does that look right?

The right answer is that the formula above will get you into a lot of trouble. It’s not as simple as that as the whole process is much more complicated.

To start, it only looks at office hours and not productive hours of the team. It doesn’t take other aspects of office life (like meetings) into consideration. To be more specific, you have to figure out how much work each individual can realistically complete during the course of the build.

To do that you have to take the following into consideration:

Number of workdays the development cycle
Company holidays during the same period
Personal vacation or paid time off allotted to each team member
Part-time vs. full-time
Time needed for emails, phone calls, and non-project meetings
Time needed to prepare and attend daily meetings
Time required to execute a contingency plan

Additionally, if you have to replace a team member, you will also have to think about the time needed to train the new recruit, deal with the backlog of work, and providing support. Then you will also have to add unplanned hours (urgent activities or meetings) and technical workshops to the framework.

So you will have to figure out how many hours will be needed by each individual based on their role that’s not going to fall under the umbrella of productive hours.

But this again does not answer the initial question. How do you figure out the ideal size of your software development team?

According to research conducted by Quantitative Software Management, smaller teams of 2 or more were highly efficient when compared to larger teams. Schedule performance also decreased as the team grew to 9 – 11 people.

The study also found that a schedule performance was the highest in 5-7 member teams with 3-5 person teams coming a close second. Larger teams were also highly cost intensive but non-linear effort didn’t really make much of a difference until the team grew to 9 or more individuals.

So you can say that the guys in the Scrum Community really knew what they were talking about because the study found that:

5-7 team members were effective. However, they were only a close second to high performing teams made up of 3-5 individuals.

The reasons behind this phenomenon can only be speculated, but a lot of them seem quite obvious. For one, the size of the team will protect against the loss of a key member. What’s more, individual performance won’t have a significant impact on the group dynamic and won’t require significant management overhead.

Communication will also be far easier in smaller teams and it will also be painless when it comes to keeping track of what everyone else is doing.

At the same time, all this is not set in stone as there might be some highly efficient large development teams out there. But for the most part, it sure looks like keeping it small, keeps you on target.