Scaling Scrum means putting more than one Scrum Team on a single product, and the Scrum Guide says almost nothing about how. Its one instruction is that Scrum Teams too large to work well should consider reorganising into several cohesive Scrum Teams, each focused on the same product, and that those teams share one Product Goal, one Product Backlog and one Product Owner. Everything past that is left to the organisation, which is why the frameworks that fill the gap all answer the same question in their own way.
That question is usually treated as a problem of coordination, when most of it is a problem of decomposition. The events and roles an organisation adds to keep its teams in step are visible, while the split that made them necessary is not.
What does not change when a product gains more teams
Some things about a product do not divide at all. A product has one Product Backlog, one Product Goal, one Product Owner, one Definition of Done and one Increment. None of that scales with the number of teams, because each of those describes the product, and the product stays one product however many teams work on it.
The Product Owner accountability is held by one person. On a large product that person cannot personally write every item, so others help with ordering, refining and talking to stakeholders. What cannot be delegated is the decision about what the product becomes, because splitting that decision produces teams pulling a single product in different directions with nobody able to settle it.
Nexus
Several frameworks exist to keep all of that single across many teams. Nexus is Scrum.org's framework for roughly three to nine Scrum Teams working from one Product Backlog, and it is deliberately thin. It adds a small amount of structure on top of Scrum and changes nothing underneath.
The framework has a published guide of its own, which Scrum.org released in 2015 and last revised in January 2021 so that it followed the 2020 Scrum Guide. Nexus therefore builds on the three accountabilities, the five events and the three artifacts, and everything it adds sits above them at the level of the whole product.
The Nexus Integration Team is accountable for producing an integrated Increment, and it exists because integration is where scaled work actually fails. Its composition is specific. The Nexus Integration Team is the Product Owner, a Scrum Master and one or more members drawn from the Scrum Teams. The members drawn from the teams need not stay the same, because the source of the integration trouble moves.
Accountability for the integrated Increment does not reach as far as performing the integration, which stays with the teams, so what this small group owns is that an integrated Increment exists at least once every Sprint. A Nexus Integration Team that takes the merge work on has become the bottleneck it was formed to clear, and that is the version scenario questions describe.
Nexus adds events that mirror the Scrum ones at the level of the whole product. Teams identify dependencies before a Sprint, surface integration problems daily, inspect the integrated Increment with stakeholders once and look at the whole Nexus in a retrospective. Refinement becomes a formal event rather than an ongoing activity, because on a scaled product the purpose of refinement is finding the dependencies before anybody commits to them.
The artifacts change less than the events do. A Nexus has one Product Backlog, one Nexus Sprint Backlog and one integrated Increment, and each Scrum Team keeps a Sprint Backlog of its own underneath. The Nexus Sprint Backlog is there to make the selected work and its dependencies visible across the teams, which is the job no single team's plan can do. Planning across the Nexus also produces a Nexus Sprint Goal for the whole product that Sprint, and each team then sets its own Sprint Goal underneath it.
The Scrum Master on a scaled product
Nexus adds a team, events and artifacts, and none of them is a Scrum Master of Scrum Masters. Each Scrum Team on the product has its own Scrum Master holding the same accountability the Scrum Guide describes, and the Guide leaves open whether one person serves more than one team, so each organisation settles that for itself.
What changes is where the impediments sit. On one team, most of what slows the work is inside the team or one step outside it. On a product split across six teams the expensive problems are the shared ones, in a release process that lets one team ship at a time, a test environment nobody owns or a Product Owner nobody can reach. Causing the removal of those shared problems means working on the organisation, which is the third of the Guide's three directions of service and the one most often left undone.
The limit is worth stating, because the split across teams is not the Scrum Master's to change. A Scrum Master can make a dependency visible, name what it costs every Sprint and decline to let another coordination event stand in for the fix, and all of that is inside the accountability. The decision about how the product is divided belongs to whoever owns the organisation's structure.
Dependencies are the work
Dependencies are what a split leaves behind, and every scaling framework provides a way to see them. Visibility helps, but it solves nothing, because two teams that must both finish before anything ships are still two teams that must both finish.
The durable fix is to change the split so that the dependency disappears. That usually means organising each team around a part of the product a customer would recognise, such as checkout or search, so that one team can finish a piece of work on its own. A product split by technical layer makes that impossible, because a single change to checkout then needs the web team, the API team and the owner of the schema to land their parts in the same Sprint.
Rearranging teams takes longer than scheduling another meeting, and it is the only change that leaves nothing left to coordinate. An organisation that keeps adding coordination without ever changing the split builds a large planning apparatus, and the integration failure it was built to prevent arrives anyway, later and more expensively.
What to check before adding teams
The question is therefore whether to add teams at all. Every team added to a product raises the communication cost and slows each decision, because more people have to agree before anything settles. That cost is worth paying when the constraint is genuinely how much can be built at once.
The constraint is often something else. When it is unclear ordering, slow releases or a Product Owner without the authority to decide, more teams make each of those worse, because every one of those problems is multiplied by the number of teams waiting on it. Scrum.org's advanced material treats this as the first question to ask, and the answer is frequently to fix the impediment rather than to scale around it.