Skip to main content

Is Nexus guide suggesting Nexus Integration Team to push work downstream to each team Sprint backlog?

Last post 05:36 pm March 16, 2023 by Klaas Behrens-Scholvin
3 replies
12:21 pm September 14, 2021

The guide says

The result of Nexus Sprint Planning is:

● a Nexus Sprint Goal that aligns with the Product Goal and describes the purpose that will be achieved by the Nexus during the Sprint

● a Sprint Goal for each Scrum Team that aligns with the Nexus Sprint Goal

● a single Nexus Sprint Backlog that represents the work of the Nexus toward the Nexus Sprint Goal and makes cross-team dependencies transparent

● A Sprint Backlog for each Scrum Team, which makes transparent the work they will do in support of the Nexus Sprint Goal

It sounds really weird that a team will have a sprint backlog pushed to them by a committee. I wonder how much it would impact engagement, ownership and even delivery. For sure the power is in the conversations team members have but I really got intrigued buy this work being pushed downstream. If it was only the sprint goal maybe it wouldn't be a problem.


12:44 pm September 14, 2021

No, there's nothing that suggests that the Nexus Integration Team pushes work to Scrum Teams.

The Nexus Integration Team is a meta-team composed of "the Product Owner, a Scrum Master, and the appropriate members from the Scrum Teams". The purpose of the Nexus Integration Team is to have a stable, consistent group of people who are working to resolve dependencies across team boundaries on a regular basis. It's also an opportunity for sharing process improvements and technical knowledge across the teams, allowing each team to maximize their freedom in selecting their way of working while ensuring the teams can produce a fully integrated and working Increment every Sprint.

At the Nexus Sprint Planning, "appropriate representatives from each Scrum Team and the Product Owner meet to plan the Sprint". Depending on the number of teams and the number of Developers on each team, "appropriate representatives" could range from one or two people to the whole Scrum Team. In the case that there is a subset, the people representing the team at the Nexus Sprint Planning could be the same people that form the Nexus Integration Team or it could be different. The people in attendance at the Nexus Sprint Planning craft a Nexus Sprint Goal that extends across all of the teams in addition to a Sprint Goal for each Scrum Team. The Nexus Sprint Backlog is a view over the Sprint Backlogs of each team. Depending on the number of teams and size of the Sprint Backlogs, the Nexus Sprint Backlog could be the sum of all of the Sprint Backlogs or an abstraction that focuses on key Product Backlog Items (such as those directly related to the Nexus Sprint Goal) or on Product Backlog Items with dependencies across Scrum Teams.

Assuming that the Nexus Integration Team members are the people who represent the Scrum Team at the Nexus Sprint Planning, those people are still pulling work in for the rest of their Scrum Team. There's also nothing preventing iteration or feedback loops where the whole Scrum Team can review the Sprint Goal and Sprint Backlog from the Nexus Sprint Backlog and rescope with the Product Owner.


06:24 pm September 14, 2021

It sounds really weird that a team will have a sprint backlog pushed to them by a committee. 

Right, and that's not what it's saying. Each individual Scrum Team will need to do its own Sprint Planning as well and within the context of any integration obligations to the Nexus.

Scaled Professional Scrum is still Scrum. Nothing is pushed, and there's no committee making any decisions.


09:38 am March 16, 2023

Mhh, are you really working with Nexus? I still @Andé that it sounds a bit like pushing things down. I guess that in most cases in the nexus integration planning the area-POs/team-POs/business analysts or however you call them of each team are present. And if they craft a sprint goal and backlog for their team it  could decrease engagement of the team. Would be interesting to hear how you experience this on practice! And if you really only have Devs on the team and no area PO would be also interesting to know how the team can prioritize on its own.


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.