Whom does the Nexus Sprint Backlog belong to?

Question

The Nexus Guide states that:

A Nexus Sprint Backlog is the composite of Product Backlog items from the Sprint Backlogs of the individual Scrum Teams.

However, trying to build an analogy between the regular Sprint Backlog and the Nexus Sprint Backlog, I got confused about the following aspects of this artifact:

• Does it belong to the Nexus Integration team or it is a shared artifact among all teams within a Nexus?
• If it is a shared artifact, does the Nexus Integration team has its own Sprint Backlog? Does it has a special name?
• Who can change the Nexus Sprint Backlog during the Sprint? (again as an analogy with the Sprint Backlog).

Answer 1

Nexus is just a buzzword for a methodology to scale a single scrum team to multiple teams. The "Nexus Sprint Backlog" should be managed by the Nexus Integration Team (Product Owner, Scrum Master, members from other scrum teams).

From the section titled "Nexus Sprint Planning":

The purpose of Nexus Sprint Planning is to coordinate the activities of all Scrum Teams in a Nexus for a single Sprint. The Product Owner provides domain knowledge and guides selection and priority decisions. The Product Backlog should be adequately refined with dependencies identified and removed or minimized prior to Nexus Sprint Planning.

During Nexus Sprint Planning, appropriate representatives from each Scrum Team validate and make adjustments to the ordering of the work as created during Refinement events. All members of the Scrum Teams should participate to minimize communication issues.

(emphasis, mine)

A sprint backlog is owned, rather is controlled by the cooperation between the product owner and the teams building the software. Within the Nexus flavor of Scrum the Nexus Sprint Backlog is the thing that helps coordinate the delivery of software by multiple teams in a single sprint.

As a contrived example, there is no sense in building a micro service that sends a message to the "notifications micro service" to send a text message, when the notifications micro service doesn't support SMS text messages. The Nexus Sprint Backlog would coordinate the work required for those two services to ensure Service A can ultimately send an SMS text message through the notification service upon release.

Answer 2

The Nexus Guide says a few relevant things.

The outcome is a set of Sprint Goals that align with the overarching Nexus Sprint Goal, each Scrum Team's Sprint Backlog and a single Nexus Sprint Backlog. The Nexus Sprint Backlog makes the work of all Scrum Team's selected Product Backlog items and any dependencies transparent.

...

All Product Backlog items selected for the Sprint and their dependencies should be made transparent on the Nexus Sprint Backlog.

...

A Nexus Sprint Backlog is the composite of Product Backlog items from the Sprint Backlogs of the individual Scrum Teams. It is used to highlight dependencies and the flow of work during the Sprint. It is updated at least daily, often as part of the Nexus Daily Scrum.

The individual Scrum Teams maintain their Sprint Backlogs, which consist of the Product Backlog Items and the work that the Scrum Team has decomposed the Product Backlog Items into. Consider that the Scrum Guide states that the Sprint Backlog "makes visible all the work that the Development Team identifies as necessary to meet the Sprint Goal". That means that a Sprint Backlog contains not only Product Backlog Items, but work that is at a finer granularity than Product Backlog Items.

The Nexus Sprint Backlog contains the Product Backlog Items being worked on by one of the teams plus the subset of work that identifies dependencies between teams. Like the Sprint Backlogs for the teams make the work of the team visible, the Nexus Sprint Backlog makes the cross-team work visible. The cross-team work is the Product Backlog Items that are intended to be delivered and fully integrated at the end of the Sprint, but also any work that requires awareness across the individuals teams to ensure that the work is delivered and fully integrated.

I would say that the primary owner is the Nexus Integration Team. However, if any one on any of the Scrum teams identifies new work that would extend across two or more teams in the Nexus, they would be able to add it to the Nexus Sprint Backlog through the team's representative on the Nexus Integration Team. Consider that the members of the Nexus Integration Team "are often members of the individual Scrum Teams in the Nexus" and that their membership in the Nexus Integration Team "takes precedence over individual Scrum Team membership". That would mean that the members of the Nexus Integration Team are responsible for and accountable for ensuring that the cross-team work items added to the Nexus Sprint Backlog are complete.