Back to Forum

NEXUS SPRINT BACKLOG ITEMS

Last post 02:55 pm April 15, 2020 by Fatima Bahaoui
3 replies
Fatima Bahaoui
08:37 am April 14, 2020

Hello all, 

 

I have a question regarding the nexus sprint backlog. The Nexus guide says that: A Nexus Sprint Backlog is the composite of all Product Backlog items from the Sprint Backlogs of the individual Scrum Teams. 

But the Nexus Framewrok for scaling scrum book says;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. Page 17

 

I am confused, would you please help me understand

 

Curtis Slough
04:59 pm April 14, 2020

Mmm I left my Nexus book at my desk in my office so I'm unable to go through the book again to verify. I'm quite certain there is another section that goes deeper into detail and provides more flavor on that.

The Nexus Integration Team meets daily to discuss integrated code and various impediments, they work through this via the Nexus Sprint Backlog. It makes sense that it would be best to limit that view to only items with problems. 

However, the 3 teams that I work with don't have a great deal of dependencies across our teams. So our Nexus Sprint Backlog is a list of all of our items across the teams within a sprint. We have this list at a PBI/Story level, not the task level as that would make it far too large. 

The answer you're looking for can be different based on what you're needing right now. If you're going towards the SPS exam, go with what the Nexus Guide says. If you're looking for the answer on how to apply this, look at the guide and the book and figure which works best for your scenario. 

Ian Mitchell
09:31 am April 15, 2020

The Nexus Guide ought to be seen as authoritative. My advice is:

  • Consider the Nexus Sprint Backlog to be the composite of Product Backlog items from the various Sprint Backlogs.
  • A filter may then be applied, which shows those items with cross-team dependencies or potential integration issues.
  • It's that filtered view which is of use in a Nexus context, because transparency over such things helps to facilitate integration and to mitigate integration risk.

Remember you will need a composite view of all items to begin with, and you have to keep that composite view updated if a filter is to tell the truth. A Nexus requires transparency over matters of integration at all times. Building and maintaining this transparency takes thought and effort.

Fatima Bahaoui
10:04 am April 15, 2020

Thanks guys! it's clearer now!

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

Please note that the first and last name from your Scrum.org 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. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org 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 Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.