"Ideal" Team Size and Ratios

A client recently asked me how many people should be on his agile team. “I have a two-person project here, and a 23-person project there. Do I want two teams, one of 2 and one of 23? Oh, and how many testers do I really need?”

I can believe there’s a small and short project that just needs two people. But when I asked him, he meant just two developers. I suggested he might want at least one tester, and what was the project? A boot ROM. I asked about the deadline. Three weeks. Was there any automated testing so far? No. Were there edge cases that were a problem? “How did you know that’s why I needed to rev the boot ROM?” (Lucky/educated guess.) I suggested three or four testers and maybe more people to develop some small simulators so the developers could test as they proceeded. “Why do I need so many testers?” Because there are so many possibilities of boards, OS’s, firmware versions, and some software, that even with combinatorial testing approaches, the fact that they felt they needed to boot all the way each test meant no test could take fewer than 5 minutes. That means a given tester is limited in the number of experiments he/she can do. If they had more time, maybe they wouldn’t need as many testers, and the developers would have to do more testing.

Now, for the 23-person project. I explained I would break that group into 3 teams, making sure there was a developer, tester, customer/ba/requirements person, writer, some sort of project-manager-type person on each team, and add however many other developers and testers the team thought they needed. “Isn’t there a correct ratio of dev to test?” No. (I discussed this in Manage It!: Your Guide to Modern, Pragmatic Project Management and Manage Your Project Portfolio: Increase Your Capacity and Finish More Projects and in It Depends.) Testing is all about obtaining enough information to assess risk. If you can’t easily test to get the information, you need more testers.

As for team size, I did some research (in addition to my experience) for Manage Your Project Portfolio, and found that while there is a somewhat ideal team size of roughly 6-8, fewer than three leads to worse decision-making. More than 9 leads to people grouping themselves into two teams. Once you have 10 or more people, the communication paths are so high that not all people have commitments to each other. Without those commitments, it’s impossible to create a team. You have a group, not a team.

I wish there was a recipe I could give you for team size and dev/test ratios. I can’t. No one can. Assess how many people need to commit to each other and how you will get the information from testing. Then you can make an informed decision.

13 Replies to “"Ideal" Team Size and Ratios”

  1. Johanna, can you post more about the research you found re ideal team size being 6-8 people? We tend to use teams of 2-4 people and I’d like to dig into how that impacts our decision making processes. Thanks!

  2. I have no research to back it up, but in my experience, when everyone is pairing (and rotating pairs) the ideal team size almost doubles.

    Pairing directly addresses the communication bottleneck you describe. And the larger (humming) team creates a much fatter pipe for work to flow through.

    Of course, I’d also say the best way to find _your_ optimal team size is to try it out different ways and measure the results.

  3. I have done numerous experiments with team size in project management classes that I teach. The ideal size for exercises in the class is 3 people. The synergistic and collaborative effects of this team size are far superior to teams of two. When I use teams of four or more, the communications and coordination of effort starts to complicate the process. I do realize that many efforts are larger than three people can effectively handle within a reasonable time frame or with the necessary skills. However, efforts with larger teams will encounter considerable overhead as team size increases. I agree that about 6-8 should be the physical limit (7 plus or minus 2?) before you start thinking about breaking the project into pieces with multiple teams. I have also become a devotee of pairing in almost all activities, but I’m not certain how this impacts team size.

  4. Pingback: Best Links of the Week – Dec 11th 2009 : Agile PM Scrum
  5. Pingback: www.webbiru.com
  6. Pingback: pligg.com
  7. Pingback: Anonymous
  8. Pingback: palnews.org

Leave a Reply