Getting confused on Nexus Sprint backlog.

Don’t think of it in a linear staged way, since Sprint Backlogs must always evolve. Remember that if teams are to collaborate and deliver a “Done” increment, then they must be able to continually integrate their work. Therefore they must evolve a shared view of their dependencies throughout the Sprint. That is the purpose of the Nexus Sprint Backlog.

That does not really answer my question. In this book it makes it sound like they are creating a new sprint backlog in between the product backlog and teams own back log called Nexus backlog. It's the recommended reading " The Nexus Framework". 

My brain is visualizing a 3rd backlog called Nexus Sprint Backlog which to be quite honest I would not implement in the real world. Thus I am still confused. 

I believe there is a third backlog.

• Nexus Product Backlog
• Nexus Sprint Backlog
• Scrum Team Sprint Backlog

The Nexus Sprint Backlog is a compilation of each team's individual Sprint Backlog and also focuses on the coordination between teams to ensure the Sprint Goal is achieved.  That is my understanding.  So, the objective of the Nexus Sprint is understood, and then each team Plans its Sprint (all part of Nexus Sprint Planning).

Alex is right.

There should be the 3rd backlog.

I’ve run scaled scrum for several years before Nexus. We called it master sprint backlog.

The PBIs in sprint backlog are owned by the whole team.

But for scaled scrum, we must know the owner(individual team) of each PBI.

We also need to know the dependency of PBIs especially for those are developed by diffenent developmeny team.

The charactors of these two sprint backlogs are different.

Thanks Alex I think you helped me clear it up. I really don't like the idea of a back log in between a back log. 

Granted I have scaled unofficially before and it worked well. We did not use a NEXUS sprint backlog because at the time that term did not exist. Now with this configuration I would have to come up with a process on my teams  so they are not confused on which container to work from or sprint back log. To me this is another level of redundancy and complexity to deal with. 

I understand a lot of answers here are based on scrum theory but I answer almost always in real world practical terms.

However I will march forward and think this way for the purpose of the exam.

I agree with Alex.

Nexus Guide: 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.

Got it - I have the Nexus guide and the recommended book " The Nexus Framework". I have a team now I don't even think we will do a Nexus sprint backlog I may remove it completely. But for the test I will adhere to the thought process. 

The only thing is, if I am indeed right, I've given you the answer without "showing my work."

Ian's response is "showing the work" to help you come up with the answer. Ian's answer will likely be more valuable in the long run!

No you are all right. It's the theory I was confused with I get it now. I just don't favor it but they did not ask me. 

There are things I never bring up in Agile\Scrum this might be one. I don't know if any benefit of the " Nexus" will be lost if I never bring up the Nexus Sprint Backlog. 

This indeed could have given more clearly in Nexus guide as it's creating a lot of confusion. 

I have similar question- Nexus sprint backlog is collection of sprint backlogs of all teams and it represents CURRENT SPRINT (Please correct if I am wrong).

But what about work items forecasted for the future to be worked on by particular team? These work items still remain in the product backlog? For example, current sprint is sprint 2. In this sprint we identified US1, US2 will be worked on by team A in sprint 4 . So, till the time we start sprint 4, US1 and US2 will remain in product backlog or will be moved to some other backlog bucket? If these work items will be moved, then in which bucket?

I'm late to the party, but I'd like to point out that in the book, The Nexus Framework For Scaling Scrum, it mentions 

The Nexus Sprint Backlog contains the PBIs that have cross-team dependencies or potential integration issues. It does not contain PBIs that have no dependencies, nor does it contain tasks from the individual Scrum Team Sprint Backlogs.

Personally I can understand the intention for doing that is to reduce the complexity. Less items listed on Nexus Spring Backlog makes it easier for you to focus on the dependencies. However, when we run scaled Agile in projects, we'd like to include all the selected PBIs on a Board, using lanes to distinguish which team works on which PBIs, no matter whether PBIs have dependencies or not. That way, everyone can have a better view on the Big Picture and teams feel more connected. Someone may argue this somehow increases the complexity. To some extent, it does, but in mitigation you can use different colors to indicate the dependencies, or put arrows/other signs on PBIs to show dependencies.

Anyway, figuring out what fits the teams best may take some time and keep in mind individuals and interactions over processes and tools.