Scrum Team Size for Developers

Scrum teams are often described as being “small” in size. But what exactly does “small” mean? The size of the Scrum team is actually quite important for the developer role. Teams that are smaller than average, larger than average, or somewhere in the middle all have their positives and negatives. Changes in team size change the team dynamic.

Recommended Team Size

No single team size works for every single project and organization. However, there is a range that tends to work best for most projects and most teams. The recommended range has been defined as 7 +/- 2 members. An average of 7 team members is enough people to get work done, but not so many that communication and administration becomes a problem. As is the case with averages, this means that some teams are larger and some are smaller. Teams smaller than 5 members are often too small to effectively cover all duties. Having more than 9 members on a team yields too many people for effective communications.

More recently, organizations have begun using a range of 6 +/- 3 team members. This range keeps the same upper end of 9 people but extends the lower end down to 3 members. For many organizations, 3 members of a team are too small. Increasingly lean methods have made 3-man teams viable for certain organizations and projects. Splitting teams also tend to yield smaller teams, and having a lower minimum allows teams to be split earlier and with less hassle.

Too Large

When a team becomes too large, it negatively affects all roles on the team, including the developers. The problems with teams that are too large all stem from communication. More people on a team means there are more people to coordinate. This adds a number of different issues. For one, meetings like the daily stand-up take longer with more people. While still not a significant portion of the day, this is multiplied across every meeting that the team has. What was once a 10-minute meeting may take 30 minutes or longer with a much larger team. With numerous meetings, this decreases the time that developers have to actually do work. Less time to do work means developers are more likely to fall behind and miss deadlines.

In addition to the time added by meetings, developers especially suffer from coordinating multiple team members for the same feature. For projects in which each developer works on a localized piece of the product, coordination is rarely a problem. However, some projects have developers working closely on the same feature. This can cause issues if developers are unsure which team member is working on what specific part. Work can sometimes be duplicated accidentally, or missed completely if every developer thought someone else was responsible. The stand-up meeting reduces the risk of these events, but does not eliminate it completely. The larger a team is, and the more developers there are, the greater the chance of work conflicts. Like the idea of “man-hours,” one developer working 8 hours may be able to accomplish much more than 8 developers working 1 hour each.

Too Small

In addition to teams being too large, teams can also be too small. Particularly for large projects, a small team of developers may be unable to finish all of the work that stakeholders need. This becomes an issue mainly when features are frequently not finished before the end of a sprint, and thus excluded from that release. Most projects can deal with having only a few developers. The developers’ velocity may be lower, but the team can organize stories such that the team still finishes new features each Sprint. However, when stories cannot be broken down small enough, developers may not be able to finish in time. Since a key part of Agile is delivering value to customers, regularly failing to finish a feature is unfitting for the team. Problems happen and any team will occasionally miss a deadline, but if this happens often, it is a key indicator that the team is too small.

<– Continue Reading –>

Our Book Recommendations

We found these books great for finding out more information on Agile Scrum:

Master of Agile – Agile Scrum Developer With 59 Seconds Agile (Video Training Course)

Introductory Offer: Free Course