Most Scrum teams lean toward 7-15 people ******, though it's not clear how to scale Scrum among 100s of people, or how the effectiveness of a given team might be compared to another team within the group; meaning beyond just breaking the group into Scrum teams of 7-15 people, it's unclear how efforts between the teams are managed, compared, etc.

Any suggestions related to either of these topics, or additional related topics that might be of more importance to account for in planning a large scale SCRUM grouping?

****** In reviewing research related to the suggested size of software development teams, which appears to be the basis for the suggested Scrum team size, I found what appears to be an error in the research which oddly appears to show that bigger teams (15+ ppl), not smaller teams (7 ppl) are better.

UPDATE, "Re: Scrum doesn't scale": Made huge amounts of progress personally researching the topic, but thought I'd respond to the general belief of some that Scrum doesn't scale by citing a quote from Succeeding with Agile by Mike Cohn :

Scrum Does Scale: You have to admire the intellectual honesty of the earliest agile authors. They were all very careful to say that agile methodolgies like Scrum were for small projects. This conservatism wasn’t because agile or Scrum turned out to be unsuited for large projects but because they hadn’t used these processes on large projects and so were reluctant to advise their readers to do so. But, in the years since the Agile Manifesto and the books that came shortly before and after it, we have learned that the principles and practices of agile development can be scaled up and applied on large projects, albeit it with a considerable amount of overhead. Fortunately, if large organizations use the techniques described regarding the role of the product owner, working with a shared product backlog, being mindful of dependencies, coordinating work among teams, and cultivating communities of practice, they can successfully scale a Scrum project.

SOURCE: (ran across the book thanks to Ladislav Mrnka answer)

  • 5
    AFAIK, scrum (and Agile in general) are about small teams. They are not supposed to scale.
    – Oded
    Commented Mar 28, 2012 at 11:32
  • Could you give a reference to the research showing that larger teams are better? Commented Mar 28, 2012 at 11:48
  • Look up scrum of scrums: en.wikipedia.org/wiki/Scrum_(development)#Scrum_of_Scrums Commented Mar 28, 2012 at 11:58
  • @Matthew Flynn: I did, read my comment I linked to in the question above, and the answer related to that comment. If it's still not clear, let me know.
    – blunders
    Commented Mar 28, 2012 at 12:01
  • @bjarkef: Thanks, please post an answer related to "scrum of scrums", since it's the most on-topic comment/answer so far. Again, thanks!
    – blunders
    Commented Mar 28, 2012 at 12:04

4 Answers 4


It's not possible to have effective scrum with such a big group. Even with twenty-something you begin to struggle. You have to divide these 100 people into much smaller task groups, which each group having their scrum. Then you can have scrum of team leaders/representatives. This is known as the scrum of scrums.

  • Right, as I stated, "beyond breaking just breaking [the] group into SCRUM teams", which is to say teams of 7-15 people, how are the teams managed and compared. If my question appears to state I'm suggestion a single SCRUM team of 100s of programmers please let me know. It's unclear why having a SCRUM of the SCRUM Masters from all the teams would be of any value in managing the SCRUM teams, how that "Master" SCRUM team would function during sprint/non-sprint time, and how the teams might be compared, or restructured.
    – blunders
    Commented Mar 28, 2012 at 12:00
  • 3
    Its actually not possible to have effective anything with such a big group. The likelihood of project failure is directly proportional to the number of people in the project. The only answer is to divide it up into smaller independent projects. Commented Mar 29, 2012 at 1:33

Scrum is intended for small teams, because the authors of scrum found that small self-organizing teams tended to be very effective in their experience. This makes sense if you consider the lean principle that hand-offs are wasteful and larger teams tend to necessitate hand-offs.

The general take on how to manage larger groups is to create a "scrum of scrums", in which case each team copes with their own sub-project, and then a member from each team represents the sub-project in a team of similar representatives from other sub-projects. This scales up as a pyramid:

           MT (Master Team for full project)
         / | \
        /  |  \
      T1   T2  T3 (Teams of Sub-projects)
    / | \
   /  |  \
 ST1 ST2 ST3 (Teams of sub-sub-projects)

Coordination of this sort of thing is tricky, but it has been done. The notion of effectiveness can be seen through the visibility inherent is scrum--burn downs and the like.

Really, if your project is so big that you need hundreds of developers, the odds are against you. You need to decompose it into workable projects that can be understood by those working on them.

  • +1 @Matthew Flynn: Thanks. So, seems like you're saying the "Project Team" is for the management of epics, "Sub-Project Teams" cover the themes, and "Sub-Sub-Project Teams" cover the user stories, right? If not, is there a structure to the workflow between the teams? Also, does your lack of reply on the comparing of teams effectiveness, and possible restructuring mean there is no known way to your knowledge to do this? (Also, if it matters, yes, the group is 100s of people, it's an experiment; while some might say to do so makes no sense, I'm looking forward to the chance to be part of it.)
    – blunders
    Commented Mar 28, 2012 at 12:40
  • That sounds like a reasonable way to deal with things, although you'll have some issues if there are inter-epic dependencies. These are problems you'd have to resolve no matter your methodology (iron-clad requirements and design often crumble in implementation). Commented Mar 28, 2012 at 16:42
  • Concerning effectiveness, the product backlog for each sub-project team would be your view into how they progress and what sort of velocity they have. Note that while velocity is not directly comparable, if you can relate each teams velocity to product points accomplished per sprint, you'll get some notion of each team's productivity. Commented Mar 28, 2012 at 16:44
  • @blunders: Alistair Cockburn discusses the amount of formalization needed as project team sizes grow in amazon.com/Agile-Software-Development-Cooperative-Edition/dp/… He deals with this by promoting differing (Agile) Crystal methodologies. Commented Mar 28, 2012 at 16:51

If you have single project with 100s of people and you want to jump directly into agile and especially Scrum you are most probably performing project suicide.

Agile development and Scrum is skill as any other. If you want to use it you must start with small project. Once you master small project you can start scaling by small steps. The best way to say that agile is not working is to convert big project from plan driven approach to agile approach without any previous experience with scaling agile.

Scaling agile is about incorporating plan driven methods on higher level. You cannot scale Scrum infinitely. The more you scale it the more plan driven mechanism will be needed. There is something called Scrum of Scrum but that is exactly something you can do only if you master pure Scrum with small team. Scrum of Scrum has also its limits - I guess something like 5-6 teams / up to 40 people.


The last assumption comes from a lot of sources including CSM and CSPO trainings, books like Succeeding with Agile and Balancing Agility and Discipline and my own experience when participating on both small Scrum team (up to 5 people) and bigger team with 15+ people divided into three teams working on the same project. The bigger the project is the more agility on higher level will be replaced with some old plan driven techniques.

Even trainer on my CSM training claimed that scaling Scrum is one of the biggest challenges the Scrum itself faces.

  • _@Ladislav Mrnka: It's unclear where the assumptions you provided came from, the most important of those being "Scrum of Scrum has [...] its limits [...] something like 5-6 teams / up to 40 people" -- what is the source of that opinion, and why is that the limit of the scrum of scrums?
    – blunders
    Commented Mar 28, 2012 at 12:14
  • 1
    I added some "sources". Commented Mar 28, 2012 at 12:25
  • +1 @Ladislav Mrnka: Thanks, appears "Succeeding with Agile" has a whole section within the book on scaling Scrum.
    – blunders
    Commented Mar 28, 2012 at 12:44
  • So, took the time to take a look at "Succeeding with Agile" at the local bookstore, and it by far has the most logical information on the subject so far. That said, I was unable to find any information in the book that would lead me to believe 40-people was the max-count for an agile product team; in fact, the scenarios described, while they I don't believe listed a member count would lead me to believe Mike was thinking of teams in the 100s. Mike in face says it does scale, and the idea it doesn't is more tied to the lack of using on that scale then it's fitness to do so.
    – blunders
    Commented Mar 28, 2012 at 15:13
  • He does talk about limiting the product backlog to 150-items, but honestly believe that logic is failed because it assume one person need to understand everything; which is a pretty limited view of the world in my opinion. That said, honestly you suggestions are the best so far, but the answer itself lacks the depth presented in Mike's book.
    – blunders
    Commented Mar 28, 2012 at 15:13

Nearly all Agile methodologies are designed for small teams, they always talk about communication as a primary aspect of the method, and the larger a team gets the more difficult effective communication becomes.

Alistair Cockburn (one of the founding fathers of Agile) has a methodology called Crystal that has different aspects depending on team size. These guidelines differ slightly but still keep to Agile principles.

An alternative is AUP, which is 'part Agile' and more suited for large teams too.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.