Scrum Dev Team Size

What does the Scrum Guide say?

3-9

SCRUM does not focus on team size, it's not that important what should be team size, the ultimate aim is to deliver the work. Yes, while allocating a team on project it should be taken care that the team should not be too small or too large.

SCRUM suggest to have a team sized between 3-9 team members. Small enough to complete the work & shouldn't be having skill constrains and large enough to be light & shouldn't be complex for healthy coordination.

Ashwin, I beg to differ. The size of the development team is between 3 and 9 people, period. The reasons for this are clearly stated the scrum guide. You may choose to have a team of 20 or 50 persons and may have great results with that, but that would not be scrum.

www.scrumguides.org

Well, theres a reason on why the scrum teams should be small. It has been studied and the results align with the scrum definition.

Jeff Sutherland mention on his books and talks about the Brooks’ Law. I will cite a fragment I found by some simple googling:

"In software development there’s a term called Brooks’ Law. Fred Brooks first coined it in his seminal 1975 book The Mythical Man-Month. Put simply, Brooks’ Law states “adding manpower to a late software project makes it later.” This has been borne out in study after study. Lawrence Putnam, a legendary figure in software development, 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 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. This result recurred over hundreds and hundreds of projects. That large teams accomplish less than small teams do seems to be an ironclad rule of human nature."

In a few words Brook's law can be generalized to "Adding people to software development slows it down"

See also, George A. Miller, The Magical Number Seven.

There are other studies that Jeff Sutherland also mention, like the one from Hackman JR, Vidmar NJ, (1970, Harvard) on optimum group size for member satisfaction showed a similar outcome. They discovered that the optimum group size was 4.6 members.

4.6 the magic number!

sources:
https://www.scruminc.com/scrum-team/
http://www.scruminc.com/wp-content/uploads/2014/10/CSMjsv18a1.pdf
https://sheilamargolis.com/2011/01/24/what-is-the-optimal-group-size-fo…

---

Long post ! hope it helps.

Well,

I have a different answer for it, team size is 6 plus or minus 3. Anywhere between 3-6 is the team size. It has been taken from the 2 pizza rule of Amazon. So its like feeding 2 pizza to the team that is the actual size. Scrum took this team size from the 2 pizza rule.

Tanmay Bhatt

Ashwin, I beg to differ. The size of the development team is between 3 and 9 people, period. The reasons for this are clearly stated the scrum guide. You may choose to have a team of 20 or 50 persons and may have great results with that, but that would not be scrum.

I always read that part of the Scrum Guide as a recommendation. A good one, sure, but still a recommendation.  The Scrum Guide does not say "The size of the development Team is between 3 and 9 people, period". It talks about optimal team size and then goes on to demonstrate that three and nine are reasonable constraints on the number of developers.

I always read that part of the Scrum Guide as a recommendation. A good one, sure, but still a recommendation.  The Scrum Guide does not say "The size of the development Team is between 3 and 9 people, period". It talks about optimal team size and then goes on to demonstrate that three and nine are reasonable constraints on the number of developers.

The guide does state that less than 3 will (not: might) result in smaller productivity gains and that more than 9 is (not: might be) "too much" for coordination reasons, so it is suboptimal if you exceed these boundaries.

I think 'recommendation' is too soft, as the boundaries are not situation dependent (though the optimal team size is).

I think 'recommendation' is too soft, as the boundaries are not situation dependent (though the optimal team size is).

Fair enough. Still it doesn't say "the development has between three and nine members" the same way it says "They are self-organizing". So I still think of it as a "softer" mandate. Personally, I wouldn't dream of breaking the 3-9 boundaries. But I wouldn't support saying a Team's not doing Scrum just because they have 10 Developers.

The Scrum Guide says:

"Fewer than three Development Team members decrease interaction and results in smaller productivity gains."

and

"Having more than nine members requires too much coordination."

"Smaller productivity gains" and "too much co-ordination" would not constitute a valid implementation of the Scrum Framework, and hence breaking the 3-9 limit with such consequences would not be an option.

If it is clear that in a particular case there would not be smaller productivity gains by breaking the limit, or that too much coordination would not in fact be the result, then different limits may hold. It would be important to know what those different limits are in that specific situation, and what evidence there is to support them. The 3-9 range is the product of careful research, and any alternative proposal or supposed improvement must also be empirically verifiable.

I think it's important to note that this is still cited during some in-person training courses, particularly by agile coaches that may not be scrum-exclusive. 7+/-2 isn't inherently "wrong," and is backed by highly-cited psychology research from the 1950s, but Scrum has more recently acknowledged that development teams of 3-4 members can still be effective.

I wonder how people would feel about trying to apply Scrum with a Development Team containing 2 members, or perhaps in the extreme case, just 1.

I'm sure many would consider it sub-optimal Scrum; but given the choice of an extremely small Development Team working within Scrum, or the same team not using Scrum, which would you expect to be more effective?

Beyond Scrum, can you really talk about a "team" when you have only 2 people ?

In "Leading Team" from Richard Hackman, the optimum balance between "potential productivity" and "process losses" is between 4 and 5 people in a team (not talking specifically about Scrum Dev Team)

See https://gerardchiva.com/2015/03/31/team-size/