Skip to main content

Getting confused on Nexus Sprint backlog.

Last post 01:51 pm August 14, 2023 by Jianhua Xu
11 replies
02:10 am June 18, 2018

SO, I am studying for Nexus and I am getting stuck on the Nexus sprint back log vs individual team sprint backlog as they are stating it. I am trying to wrap my mind around and almost there but the real-world implementation(how I see it) and as stated in the book are confusing me.

In 2012 I worked for a government agency we had six teams that struggled with this. We were doing scale sort of but not really, we just had a need for all teams to work from the same product backlog. Our product back log we had down no problem. When we did the sprint planning each team knew what was their PBI’s and brought them over to their own team’s boards. No real problem I just met weekly in the scrum of scrums which I led to discuss dependencies, impediments, and progress. I did have to aggregate 6 burndowns but no big deal.

In the book I bought the application does not sound the same. They are doing Product Backlog—Nexus Sprint backlog – then individual team Sprint back log.

My question is on flow – Are they saying in Nexus that once the Product backlog refinement has taken place the team Nexus sprint planning is pulling product backlog items from the Product Backlog – Into the Nexus Sprint Planning back log – then into each team’s own sprint backlog?

Here is what I am trying to say below I tried to paste a pic but it did not work.

Product Backlog (all PBI’s) --- Nexus Sprint Backlog (PBI’s pulled from product backlog in agreement with PO) – Each teams pulls it’s PBI’s from the Nexus Sprint backlog into their own Team backlog’s. 

06:28 am June 18, 2018

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.

11:29 am June 18, 2018

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. 

12:38 pm June 18, 2018

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).

01:53 pm June 18, 2018

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.


02:47 pm June 18, 2018

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.

02:54 pm June 18, 2018

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.


03:05 pm June 18, 2018

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. 

04:00 pm June 18, 2018

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!

04:08 pm June 18, 2018

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. 

07:38 am November 19, 2018

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?

01:01 am August 13, 2023

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. 

By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by may have their access revoked at any time, without warning. may, but is not obliged to, monitor submissions.