Team Size Can Be the Key to a Successful Software Project

Team Size Can Be the Key to a Successful Software Project

The Research

People frequently ask if there is an optimum staffing level for a software development project? At one extreme, the number of people could be below a critical mass and the project is vulnerable to the loss of a key person. Very small teams are also highly dependent on the skills of the "individual". At the other extreme, large teams experience human communication complexities. Large teams quickly gravitate toward the average skill set of the group. Somewhere in the middle there should be an optimum situation. So, the quick and dirty answer to the question is; yes there is an optimum team size, but it is dependent on a number of variables. Some obvious variables are:

  • The size of code to be developed and reused
  • The application complexity
  • The degree to which schedule or cost is the overriding schedule constraint

In this research, we set out to find the optimum staffing for a specific application domain and size regime. In this work we will define optimum staff size as the team size most likely to achieve the highest productivity, the shortest schedule, the cheapest cost with the least amount of variation in the final outcome.

Our Method

To minimize the variables that could impact our results we decided to select a set of medium sized information systems that were completed in the last 3 years. Medium sized was defined as products that contained 35,000 to 95,000 new or modified source lines of code. There were 491 projects that satisfied the conditions. The sample was then stratified into team size groupings, which is shown in Figure 1. Notice that all of the data sets are fairly well distributed across the entire size regime. The average size of all 5 data sets is 57,412 ESLOC. None of the data set averages are more that 3,000 SLOC away from the overall average size.

Average Staffing vs. Size graph

The Results

The average productivity, schedule and effort were analyzed for each of the data sets along with the standard deviation. We plotted the averages and compared them to see which had the best performance and observed overall trends if they were apparent.

Productivity Data

The average Productivity Index (a measure that uses size, schedule time and development effort in it's calculation) was calculated for each of the 5 data sets. The Productivity Index for the 1.5-3, 3-5 and 5-7 person data sets were very similar and had the highest level of efficiency. The "smaller teams" were 2 or more Productivity Indices higher than the "larger teams". The 5-7 person data set had approximately 9% less variation than the 3-5 person projects and 12% less variation compared to the 1.5 - 3 person projects. The variation is displayed using the high-low bars which represent one standard deviation from the average.

Average Productivity Index gantt chart

Schedule Data

The schedule data shows that there is a decreasing trend in schedule performance as the team sizes get larger until the team size reach 9-11 people where the average time starts to increase. The schedule performance data show the 5-7 person data set as having the best performance, however the 3-5 person data set is a very close second.

Average Schedule in Months gantt chart

Effort Data

The development effort statistics show that larger teams translate into more effort and cost. The trend appears to have a exponential behavior. The most cost effective strategy is the smallest team, however the extreme non-linear effort increase doesn't seem to kick in until the team size approaches 9 or more people.

Development Effort gantt chart

Conclusions

The goal of our research was to find optimum team size for building medium sized information systems. From the 491 projects that were analyzed we would conclude that a 3-7 person team has the best performance (3-5 would be the best, but 5-7 people is a very close second). The 3-5 person data set was not the outright winner in any of the assessment categories however it had very good performance in all areas. One can speculate on why we see this behavior on the moderately small teams, but common sense suggest the following reasons:

  • This team size provides some protection against the loss of a key person.
  • Individual performance is not overcome by group dynamics.
  • Team size is probably close to optimum in building motivation and cohesion.
  • There is minimum human communication complexity among team members.
  • It doesn't require significant management overhead.

Next time you are planning a project think hard about the optimum staffing levels because it can clearly have a significant impact on the overall results. This study gives you some insights into an application and size domain where many systems are being built today. Coupled with good peopleware practices you should be able to make a real impact on your organization's bottom line performance.