Multiple Teams and the Scrum Guide

Teams ought to assure transparency over shared work via the Product Backlog:

"Multiple Scrum Teams often work together on the same product. One Product Backlog is used to describe the upcoming work on the product. A Product Backlog attribute that groups items may then be employed."

Teams are jointly responsible for integrating a "Done" and release-ready increment:

"If there are multiple Scrum Teams working on the system or product release, the Development Teams on all the Scrum Teams must mutually define the definition of "Done"."

@Ian Mitchell,  The Scrum Guide doesn't say how many teams in the context of multiple teams, would it be right to take that guidance i.e. 3-9 teams from the Nexus Guide?

Would it be right to consider that the Nexus Guide is an extension of the Scrum Guide? If No, then, what guidance should we take, strictly from the Scrum Guide alone, in the context of multiple teams?

I wouldn't say that, Nexus and Scrum are different frameworks and are used for different situations. Nexus and Scrum are related since Nexus uses Scrum as the foundation of Nexus. If you're looking for guidance on multiple teams using the same product backlog, it may be helpful to look at the Nexus Guide but keep in mind that the guidance found there is specific to following the Nexus Framework; it may not make sense to take bits and pieces out. 

Scrum’s roles, events, artifacts, and rules are immutable and although implementing only parts of Scrum is possible, the result is not Scrum. Scrum exists only in its entirety and functions well as a container for other techniques, methodologies, and practices.

Scrum allows you to make any arrangements you like, as long as it doesn't contradict the Scrum Guide. So I suggest do the minimum that is needed to allow those teams to work most effectively.

What bits of the Scrum Guide don't seem to fit well when you have multiple teams? Why?

Maybe there is a lean solution to that problem that is still Scrum.

If you just have two teams, the overhead of a full scaling framework is probably not necessary. It might not even be necessary with more teams.

The Scrum Guide is written about a single team. There are a number of frameworks that take the core concepts of Scrum and scale it to multiple teams. Nexus is one option. Scrum @ Scale is another. Large-Scale Scrum (LeSS) is a third. There may also be other frameworks that represent "scaled Scrum", but those are the three that I'm most familiar with.

These scaled Scrum frameworks begin to see value with 3 or more teams supporting a single Product Backlog. I'm not aware of any framework that starts with two teams, with the common thinking is that two teams working together doesn't require a lot of special considerations or coordination overhead.

I'm not sure what guidance that you can't take away from the Scrum Guide in the context of multiple teams. Frameworks such as Nexus, Scrum @ Scale, and LeSS don't make drastic changes to the roles or events. It should be straightforward to think through how to apply them all with two teams and then look at how others have scaled Scrum to three or more teams.

Are there particular problems that you are experiencing with multiple teams working from a single Product Backlog?

If you just have two teams, the overhead of a full scaling framework is probably not necessary. It might not even be necessary with more teams.

@Simon Mayer, I agree with you on this.

I don't really have any problem using Scrum with multiple teams. I was just asking out of curiosity if there is a specific number when the Scrum Guide says "multiple teams".

The two teams one backlog makes sense.  What about scrum events?  Does each team have its own retro, planning, daily scrum, reviews?  

What about three teams, one backlog?  

The two teams one backlog makes sense.  What about scrum events?  Does each team have its own retro, planning, daily scrum, reviews?  

What about three teams, one backlog?

Regardless of the number of teams, there is one Product Backlog per product. This applies to 2 teams, 3 teams, and more teams.

Different frameworks have different ideas on how to scale the events. Although the frameworks tend to be geared toward 3 or more teams, you can still look at Nexus and LeSS for suggestions. There is also Scrum@Scale, but I've had less success with some of those ideas.

Chances are that you will need to have some shared component to Sprint Planning to iron out dependencies, and both Nexus and Less have a combined session followed by the teams splitting into more detailed team planning.

The Daily Scrum is often on each individual team, with Nexus adding the Nexus Daily Scrum for "appropriate representatives" from each team while LeSS favors more ad-hoc cross-team coordination. Scrum@Scale introduces the Scrum-of-Scrums, and this is compatible with (but not encouraged) LeSS.

Sprint Reviews are best suited for the product level, so there would likely be one review across all of the teams. Although it's not part of any of the frameworks, I have found that setting aside for a "technical review" for the teams could be a good idea and align teams on architectually-significant decisions.

Retrospectives should be both internal to the team as well as across the team boundaries. This gives the opportunities for each team to improve their own internal ways of working, but there also needs to be time for teams to reflect and improve on how they work together to deliver each Increment. Nexus has a three phase Sprint Retrospective with the whole group, individual teams, then the whole group again. LeSS calls for two - each individual team and then the whole group.

I would recommend experimenting. I've found the ideas in both Nexus and LeSS to be fairly reliable as a starting point, but there could be other options as well. I would recommend avoiding tying yourself to any one framework and being willing to experiment to see what provides the best results for the teams working together.

Multiple Scrum team have multiple scrum master?

I don't really have any problem using Scrum with multiple teams. I was just asking out of curiosity if there is a specific number when the Scrum Guide says "multiple teams".

I think it is less about a number and more about the need.

As Simon mentioned the overhead of Nexus or another scaling framework may not be worth it for 2 or even 3 teams. The juice may not be worth squeeze. 

If you find that you are struggling to manage dependencies and integrations with 3+ teams, the overhead of including Nexus may be worth it for your situation. 

Multiple Scrum team have multiple scrum master?

According to the Scrum Guide each Scrum Team has one Product Owner, one Scrum Master and Developers.  So if you have 2 teams, each one will have a Scrum Master.   

That's the textbook answer.  However in practice I have seen one individual be the Scrum Master for multiple teams. Personally, I have been a Scrum Master for up to 4 teams at the same time.  It all depends on the maturity of the teams.  A team just beginning their Scrum journey would best be served by a dedicated Scrum Master. But a team that has been working together for a while and have become comfortable with their roles, cadence, and self-organization may not have need for a dedicated Scrum Master.