Development Team Size
Scrum guide recommends that dev. team size should be between 3 and 9. I took that for granted since scrum guide says it and it stated that this is based on research. Now, I had someone interested in that research
Could someone point me where I can find such research?
In 2003 Jeff Sutherland recommended constraining teams to less than 7 members:
This has crept upwards a bit, and the maximum is now variously quoted as being 7 (Scrum Primer) or 9 (Scrum Guide).
Jeff cited the following research:
Rubin, Howard (Ed.) A Metrics View of Software Engineering Performance Across Industries. IT Metrics Strategies V:9:3, September 1999.
Thanks for pointing to the Jeff's recommendation. This helps from general perspective but I am still looking on what bases Scrum Guide says it is 3 to 9. Number has slightly increased and I am sure there are some data to support this.
I guess, Scrum Guide authors should chime on this one and help community with some research data why they decided to increase team size.
The number hasn't increased as it used to be 7± 2. Now it is 6 ± 3. So the max is still 9, but the range was increased in the Scrum Guide as there are plenty of successful Scrum development teams with 3 or 4 members.
The original 7 ± 2 came from a psychology paper called "The Magical Number Seven, Plus or Minus Two: Some Limits on Our Capacity for Processing Information" where it demonstrates that there are limits to how much information we can keep in our heads. In Scrum teams, as in other teams that work in complex environments (Marines, Navy Seals, Sports), keeping high bandwidth communication and relationships is essential. This becomes more difficult once we pass that magical number of '9'.
More information about that paper here: http://en.wikipedia.org/wiki/The_Magical_Number_Seven,_Plus_or_Minus_Two
Hope that helps!
In "Succeding with Agile", Mike Cohn wrote a full chapter (10) about team structure. He quotes some research inside his writing.
He push the idea of "2 pizzas teams" and numerous reason why big teams are not efficient.
I found it very interesting !
Hope it helps
This gives me enough research data points how Scrum Guide came with the dev. team size.
Thank you all for your input.
Incidentally the two pizza team rule originated with Jeff Bezos on the principle that "communication is terrible". The next time you hear someone say "we need to communicate more in this organization", it's worth bearing this in mind. Such statements should not be considered equivalent to an appeal for "individuals and interactions". Chances are it's the dependencies between teams that are the problem, not insufficiently complex lines of communication.
Posted By Don McGreal on 22 Feb 2014 10:32 AM
The original 7 ± 2 came from a psychology paper called "The Magical Number Seven, Plus or Minus Two: Some Limits on Our Capacity for Processing Information"
Hope that helps!
It does help in spreading the common misconception about a "magical" number 7.
Please read the paper you refer to, see http://www.centigrade.de/blog/en/article/the-number-seven-is-not-magica… and/or do some additional googling.
I'm new in scrum world (about one year). I have a question. What should Scrum Master do when Product owner came to him and ask for team 15 engineer? I know that this team is not scrum, but he want to work in scrum with them.
Empiricism asserts that knowledge comes from experience and making decisions based on what is known.
Having more than nine members requires too much coordination. Large Development Teams generate too much complexity for an empirical process to manage
The Scrum guide cites those issues with being present in teams over 9 members. These are concerns, not failing points, and a Scrum team of more than 15 members can work. However it won't be as effective as an appropriately sized team. Ideally you'd separate them out into two teams, and follow the Nexus Guide for scaling Scrum out to multiple teams. That is the Scrum.org method for scaling Scrum. You could also look into SAFe, as a second method for agile scaling.
The biggest problem you'll find likely isn't the labor, but the events. Keeping a Daily Scrum time boxed to 15 minutes can be challenging with 7 people, and doubling that team size makes it much harder. Expanding the time box is a no-go (after 15 minutes, you start to lose the benefits of a "stand up" meeting), and you're going to have to better prepare for the other events by clarifying things in advance.
As I understand it, your job as a Scrum Master in this scenario gets harder, but not impossible. You can have a 15-man Scrum Team, but since the events are based on the sprint length and not the team size, you'll find yourself less in the servant role and more in the leader role. You need to put extra focus into making sure things are done efficiently, because you have less room (and less time) in your schedule as a margin of error. Someone going off on a tangent is going to have a deeper impact on a large team than a small one.
No edit button. Just clarifying that response was towards Filip.
Jason Jafarian thx! Your post gave me answer for my problem.