3-9 team size - interpretation of scrum guide

I suggest not to follow all the things you read 100%. Pick the ones that your team will be comfortable with and check.

Do not aim for the perfect-optimal thing, it does not exist.

@Sherwin Soriano - well said! :)

If my understanding is right, then research has shown that the most effective teams usually have between 3-9 people. This doesn't mean teams larger than this can't be effective, however, they may run into issues collaborating and communicating.

So, if you have a Development Team that has more than 9 members, this doesn't necessarily mean you have to split the team. If they (Development Team with more than 9 members) are able to effectively work together and produce a "Done" Increment, then such an exercise is wasteful.

The bottom line is Inspect & Adapt.

@Monika Pluciennik, Hope that helps clarify your question?

It's a recommendation. You can have 10 or 11 members and still be a Scrum Team if you are following the rules of Scrum that are laid out in the Scrum Guide.

The idea of 3 to 9 members comes from effectiveness of the events.

For extremely small teams, look at the Daily Scrum. There's little point in holding a Daily Scrum with 1 person, but I suppose they could use 15 minutes for similar purposes. I would tend to consider the formality of the Daily Scrum event to be an unnecessary overhead for 1 person. Likewise, when you get to 9, 10, and 11 people, it becomes harder to effectively coordinate and replan in a 15 minute timebox.

The Sprint Retrospective is another event that becomes harder. Not only do you have the Development Team at this event, but whole Scrum Team, so you'd possibly add two more people for the Product Owner and Scrum Master. Once you start getting into larger teams, it becomes more difficult to fully engage the whole Scrum Team within the timebox and have an effective event.

Consider the formula for communication pathways on a team: n (n – 1) /2. For a Development Team, there are 3 communication pathways. With 9, this grows to 36 and with 11, to 55. When considering a Scrum Team, you may add two more (a Scrum Master and a Product Owner) to go from 5 people with 10 pathways to 11 people with 55 pathways to 13 with 78. This shows the growth in complexity and communication overhead as your team grows. Scrum does a decent job of reducing the overhead with how the events are designed and structured, but it can't be eliminated.

@Steve is right, it has to do with research regarding effectivity in team dynamics (Ringelmann's famous study back in the 1800s for instance looked into team size when pulling a rope). Usually having less than 3 people creates redundancy in meetings and might not get you to a "Done" Increment of potentially releasable product, whereas more than 9 people increases complexity that could get in the way of efficiency. It has a lot to do with the team dynamics, so indeed inspect & adapt whether it works for your team and if not how to improve.

@Thomas, be careful calling it a recommendation. I had a discussion with Stephanie Ockerman a few months ago why calling it a recommendation can be dangerous (long story short, people tend to take the recommendation as a guideline, hence why the Scrum Guide calls it optimum). 

However still there is no clear conclusion if the number MUST be between 3-9 members or is recommended.

I would agree that Guide has suggested the optimal number of team size not that you must have.

So for example team that has 10 members &  follow up scrum guide would be a scrum team, not perfect=not optimal and if a team collaborate well does not need to be split into 2 teams?

Are there enough evidence that this team of < or =10 people collaboratively deliver potentially releasable increments of highest value?

If yes then , is the splitting of teams still desirable ?

If no then, can this splitting into smaller teams may decrease complexity for an empirical process to be useful ?

As a ScrumMaster you'll have to figure out the min and max yourself.

In my opinion 6 is the perfect number.

9 is too many, I have 9 now in one of my teams, we struggle to keep the standup to 15mins. It's more difficult to identify if someone is struggling too as they can get lost in the noise for a couple of days.

Retrospectives are long.

Planning sessions take longer too with many more opinions and disagreements to discuss. 

I have a cautionary tale from my prior experience as a Scrum Master of two teams, each of which grew steadily to 10 developers.

They each had 9 engineers, plus one UX specialist who was in both teams.

The decision to recruit into the teams, and build them to such a size was a deliberate onboarding strategy, and the risk that these teams wouldn't be able to function properly was anticipated in advance.

I was surprised that in the short term, there were no obvious ill-effects of such large teams. Team members were happy, and new colleagues generally felt productive.

In the end, it turned out that a lack of accountability and clarity about product ownership meant that the dysfunctions of such teams were not immediately exposed.

After several sprints, patterns began to emerge in both teams, where Sprint Goals would be multi-threaded, and each team would informally split for the duration of a sprint into semi-persistent sub-teams, working towards a separate aspect of the goal.

At best, you could consider this self-organization to meet the demands placed on the team. At worst, it was a dangerous non-transparent anti-pattern, where accountability was further obscured, and Scrum events were lip-service to a collective that were not really functioning as a team.

Ultimately, I realized the need to expose pain-points, such as incoherent Sprint Goals which were often difficult to form, lengthy Scrum events that were of limited interested to large parts of the team, and a general indifference when certain team members picked up work that was not related to the Sprint Goal. This helped members of both teams eventually speak up and trigger a restructuring into smaller teams.

Simon I have a very similar story but it has not been resolved yet.

One team is at 9 devs, arch and eng manager. Another dev has been added now and I have heard there are more coming.

Accountability, ownership, silos, sub-domains are a big issue which I have highlighted and tried to address but with only some improvement.

I'd like to hear more about how the team split and the communication between both and the logistics of it all. 

so I would interpret this as recommended size.

My advice is to interpret it as an observation about risk. When team size is suboptimal development risk will increase. Whether that risk is acceptable or not will depend upon a team's operating context.

Since each context cannot be foreseen in the Scrum Guide, the Guide can't strictly be said to make recommendations.

Thank you all . It is clear now . 

I'd like to hear more about how the team split and the communication between both and the logistics of it all. 

We have some limitations, such as a single code-base, and arguably just one product. This means that having multiple Product Owners, Product Backlogs and Scrum Teams doesn't necessarily fit neatly with that reality.

Previously, we had minimal transparency over what each Product Owner owned, such that the two teams were named after colours, and work was assigned to each team, based on rather subjective criteria.

We're a small enough company that management were close enough to the pain points. Once engineers were speaking up to their manager, there was already a trigger for this to be raised in a meeting of the whole engineering team, and the manager proposed a structure, after discussing with me, Product Owners and other managers.

We now have three teams, each with its own Product Backlog, and each with a mission, which generally informs which team will progress with a new initiative. The Development Teams all also agreed areas of code ownership, which generally determines which Product Backlog a bug goes on.

We still have two Product Owners, so one owns the Product Backlog for two teams.

Three developers stepped out of the teams, in order to provide support to the teams, rather than working inside a Scrum Team. These were our two QA engineers and our UX specialist.

For unrelated reasons, one engineer left, neatly bringing the total available developers to 15 for three teams.

Based on a knowledge of the missions and who was Product Owner for each backlog, the engineers were asked to choose their preferred team; subject to certain constraints, such as each team having a certain balance of skills, and no team exclusively containing members of either of the two previous teams.

Ultimately, everyone did manage to join a team that they had chosen.

I think we have a decent solution for our context, and it definitely helps. I think we could have something better, but we've resolved our most significant pain points, and it's not the area I'm currently most focused on changing.