Image source Larry Maccherone, AgileCraft from Impact of Agile Quantified – Late 2014 Edition, slide 95
What’s the “right” Agile team size? Smaller is better. A collection of excerpts and quotes on Agile team size, you may find this useful in discussion with Product Owners and those “paying the bills”. Empirical data is paramount to show how and why a specific team size is best in your situation:
Development Team Size
Optimal Development Team size is small enough to remain nimble and large enough to complete significant work within a Sprint. Fewer than three Development Team members decrease interaction and results in smaller productivity gains. Smaller Development Teams may encounter skill constraints during the Sprint, causing the Development Team to be unable to deliver a potentially releasable Increment. Having more than nine members requires too much coordination.
Schwaber, K. and Sutherland J. 2017, The Scrum Guide, available from www.scrumguides.org, 2 February 2018.
Scrum Team Size
I’ll keep this next section short and sweet because there really isn’t any contention in the community on this particular topic. As Mike Cohn confirms in his most recent book, Succeeding with Agile (2009), “The generally accepted advice is that the ideal Scrum team size is five to nine individuals.” I’ll simply add that my preference is for the lower side—typically five to seven.
Development Team Ratios
When it comes to determining the makeup of the development team, there is certainly no one-size-fits-all rule because every project and team is different. However, if you have no idea where to start, to get you going, I suggest a ratio that I have worked with successfully on multiple occasions (although I highly recommend that you inspect and adapt accordingly):
3 programmers : 1 tester : 0.5 “deep specialist(s)” (This ratio assumes a high level of test-automation maturity)
Goldstein, I. 2014, Scrum Shortcuts Without Cutting Corners: Agile Tactics, Tools & Tips, Pearson Education, Inc
Size Does Matter, but Not the Way You Think
In software development there’s a term called “Brooks’s Law” that Fred Brooks first coined back in 1975 in his seminal book The Mythical Man-Month. Put simply, Brooks’s Law says “adding manpower to a late software project makes it later.”8 This has been borne out in study after study. Lawrence Putnam is a legendary figure in software development, and he has made it his life’s work to study how long things take to make and why. His work kept showing that projects with twenty or more people on them used more effort than those with five or fewer. Not just a little bit, but a lot. A large team would take about five times the number of hours that a small team would. He saw this again and again, and in the mid-1990s he decided to try to do a broad-based study to determine what the right team size is. So he looked at 491 medium-size projects at hundreds of different companies. These were all projects that required new products or features to be created, not a repurposing of old versions. He divided the projects by team size and noticed something right away. Once the teams grew larger than eight, they took dramatically longer to get things done. Groups made up of three to seven people required about 25 percent of the effort of groups of nine to twenty to get the same amount of work done.
…
Just as on a Special Forces team, everyone on a Scrum team has to know what everyone else is doing. All the work being done, the challenges faced, the progress made, has to be transparent to everyone else. And if the team gets too big, the ability of everyone to communicate clearly with everyone else, all the time, gets muddled. There are too many crosscurrents. Often, the team socially and functionally breaks into sub-teams that begin working at cross-purposes. The cross-functionality is lost. Meetings that took minutes now take hours.
Don’t do it. Keep your teams small.
Sutherland, K. 2014, Scrum: The Art of Doing Twice the Work in Half the Time, Crown Publishing
Agile Teams
The SAFe Agile Team is a cross-functional group of 5 to 10 people who have the ability and authority to define, build, and test some element of Solution value—all in a short Iteration timebox. Specifically, the SAFe Agile Team incorporates the Dev Team, Scrum Master, and Product Owner roles. [ie maximum 8]
www.scaledagileframework.com/agile-teams
…the Scrum Guide says that the optimal team size is seven people, plus or minus two. In short, the team should number between five and nine people. Teams of three to four people can work very well (we’ll see that further on in this article). But it is clear is that teams should, ideally, not have more than nine members. Why is this the case?
By 1983, Ikujiro Nonaka and Hirotaka Takeuchi were formulating the ideal team size after conducting research and building new products in technology companies such as Fuji Xerox, Canon, Honda, Epson, Brother, 3M, and Hewlett-Packard. These studies and later work by Jeff Sutherland and Ken Schwaber demonstrated the following levels of productivity based on team size:
Agile Team Productivity Non-Agile Team Productivity < 7 members 300-400 % < 7 members 100% max > 7 members 400% > 7 members < 90% A small team of three to four people can be very autonomous when it is following guidelines and has a well-defined focus, and everyone is physically in the same space. Their work is often consistent, responsible, aligned, and well targeted, and communication is fluid. Things are relatively easy when there are only a few individuals on the team. Problems appear to increase along with the number of team members.
www.scrumalliance.org/community/articles/2016/october/the-size-of-a-scrum-team-or-scaled-scrum-team\
There is plenty of data to show that team sizes over 7 result in significantly lower productivity. Any team over 7 in size should be split up into multiple SCRUMs. (author highlighting)
en.wikipedia.org/wiki/The_Magical_Number_Seven,_Plus_or_Minus_Two
Harvard Professor Hackman died last year. His book Leading teams is a classic and he pointed out that his research showed the right team size averages 4.6. Do your own research. At Scrum Inc. we consistently find teams of 4 or 5 people are most productive.
Rubin, Howard (Ed.) A Metrics View of Software Engineering Performance Across Industries. IT Metrics Strategies V:9:3, September 1999.
www.scruminc.com/scrum-keep-team-size-under-7
In his book Succeeding with Agile, Mike Cohn offers an easy way to tell whether you have the perfect team size. If you can feed the whole team on two pizzas, you’re there.
Adkins, L. 2010, Coaching Agile Teams: A Companion for Scrum Masters, and Project managers in Transition, Addison-Wesley
