Is Nexus guide suggesting Nexus Integration Team to push work downstream to each team Sprint backlog?
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.
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.
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.
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.