What is the Ideal Scrum Team Size in Agile Projects. What happens if the Scrum Team size is too small or too big? Are there any consequences for the Agile Project?
Ideal Scrum Team Size
A 59 Seconds Agile Video Animation
Ideal Scrum Team Size In Agile Projects for Scrum Developers
A 59 Seconds Agile Article
Scrum teams are often described as being “small” in size. But what exactly does “small” mean? The size of the Scrum team (Scrum Master, Product Owner and Development 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.
Ideal Scrum Team Size and the 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.
Ideal Scrum Team Size: 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.
Ideal Scrum Team Size: 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.
Prev <— Continue Reading —> Next
Learn More: Estimating and Planning User Stories
User Stories Applied
A 59 Seconds Agile Book Review
User Stories Applied by Mike Cohn is one of our favourite books on Agile User Stories. The book starts with an overview into user stories, and details what a user story is and the different aspects of them. He then discusses how to go about writing a user story, and provides details of the INVEST criteria that can be used to determine if the story is meeting all of its objectives. Next Mike gives an in depth discussion of who user stories are written for and where to begin when gathering the details for them. The book then discusses acceptance testing user stories, including how to go about specifying these criteria and the responsibilities of the development team and customers during this process.
Prev <— Continue Reading —> Next
Learn More: Estimating and Planning User Stories
Estimating Scrum User Stories
A 59 Seconds Agile Infographic
Prev <— Continue Reading —> Next
Learn More: Estimating and Planning User Stories
Our Favourite Agile Books
We found these books great for finding out more information on Agile Scrum: