Nexus Guide questions

Or does it say that all team members join the Nexus Sprint Planning but that that first step of validating and adjusting the ordering is only done by some "appropriate" members?

I go for the answer.

-- Nexus Sprint Planning - when are PBIs picked? --
The Nexus Guide does not explicitly say at which point the Scrum Teams pick Product Backlog Items into their individual Sprint Backlogs.

It is described at the Nexus Process Flow

Nexus Sprint Planning: Appropriate representatives from each Scrum Team meet to discuss and review the refined Product Backlog. They select Product Backlog items for each team. Each Scrum Team then plans its own Sprint, interacting with other teams as appropriate.
...

-- Scrum Team Roles --

Just to double-check: My understanding is that in a Nexus, the individual Scrum Teams do *not* have Product Owners. They all work with the one Nexus Product Owner. Is that also your view?

Yes and No.
There is only one Product Backlog for all Scrum Teams of the Nexus.
And there is only one Product Owner for all Scrum Teams of the Nexus.
You could not say "the individual Scrum Teams do *not* have Product Owners"
My opinion is a Product Owner is solely a Product Owner. There is no role named "Nexus Product Owner"

> What does this say? That *at least* some
> "appropriate" members from the Scrum
> Teams join the Nexus Sprint Planning...

The Nexus Guide says: "Members of the Nexus Integration Team may also work on the Scrum Teams in that Nexus, as appropriate and necessary".

Nexus Sprint Planning illustrates this in practice. Those Scrum Team members who are also members of the Integration Team have a responsibility to prepare the Product Backlog so that individual Scrum Team Sprint Planning events can be facilitated. They will pay close attention to integration dependencies and ordering.

All of the members of the various Scrum Teams in the Nexus must also participate in Nexus Sprint Planning, as they are expected to conduct their own Sprint Planning afterwards. To do this they must understand and share the Nexus Sprint Goal.

> My understanding is therefore that the
> picking takes place in the Nexus Sprint Planning.

No, that should occur in each team's own Sprint Planning session. The Scrum Framework must be observed.

The Nexus Sprint Backlog is an aggregation of the PBI's of all Sprint Backlogs in the Nexus. Therefore it should *not* be seen as an output of Nexus Sprint Planning. Rather, it is shaped during individual team Planning Sessions, and it will evolve during the Sprint as the various Sprint Backlogs also evolve.

Nexus Sprint Planning is for the mitigation of integration dependencies in those Product Backlog items thought necessary to meet an identified and shared Nexus Sprint Goal.

> My understanding is that in a Nexus, the
> individual Scrum Teams do *not* have
> Product Owners. They all work with the one Nexus Product Owner.

Each team must have a Product Owner. One discrete product means there must be one Product Owner, regardless of the number of teams needed to deliver product increments.

> The Nexus Sprint Backlog is an aggregation
> of the PBI's of all Sprint Backlogs in the
> Nexus. Therefore it should *not* be seen as
> an output of Nexus Sprint Planning. Rather, it
> is shaped during individual team Planning Sessions

Correction, I should have said that the Nexus Sprint Backlog "should *not* be seen as an output of that part of Nexus Sprint Planning which is not individual team Sprint Planning. Rather, it is shaped during those individual team Planning Sessions".

This is because although individual team Sprint Planning events are separate sessions, Nexus Sprint Planning is not complete until these events are complete. The Nexus Sprint Backlog may therefore be reasonably seen as an output of Nexus Sprint Planning.

Thank you both for taking the time to look into this!

You are right that my phrasing for the Product Owner role was not good. The Nexus has one Product Owner. That person also serves as Product Owner in the individual Scrum Teams. So I imagine that during the part of the Nexus Sprint Planning that is the Scrum Teams' individual Sprint Planning, that person is available for all Scrum Teams in case of questions.

Ian, thanks for pointing out that the Nexus Integration Team Members who also work on the Scrum Teams are the most "appropriate" representatives for the first part of Nexus Sprint Planning. It made me wonder what would happen if Nexus Integration Team Members were *not* firmly rooted in the Scrum Teams' work. The risk might be to get some kind of "ivory tower" Nexus Integration Team, which is probably an anti-pattern to the values of Scrum.

I was wondering about what you said about the selection of PBIs into the Nexus Sprint Backlog. As Li Ching-Pei pointed out, there is a section in the Nexus Guide that states: "Appropriate representatives from each Scrum Team meet to discuss and review the refined Product Backlog. They select Product Backlog items for each team. Each Scrum Team then plans its own Sprint, interacting with other teams as appropriate."

So there does seem to be some selecting of PBIs by the representatives before the separate Sprint Planning events. I now suspect that maybe both is true? That there is that first "pre-selection" by the representatives, which serves as an assumption to build the Nexus Sprint Goal and to start the separate Sprint Planning events. But that the "real" planning of the Nexus Sprint Backlog happens in the individual team Sprint Planning, which concludes the Nexus Sprint Planning.

Does this sound about right?

Both Scrum and Nexus is simple to understand but difficult to master.
So, don’t overthink it to avoid stepping into the text trap.

The Product Owner is not the Team Owner.
The Product Owner is responsible for Product not for the Team solely.

The Product Owner is responsible for maximize the VALUE of the product and the VALUE of the work of the Development Team.

So, there is one Product Owner for one Product no matter how many teams collaborating to develop the product.


For PBIs, there are clearer processes described in the “Nexus Flow Process” section.

Per my experiences, there are some thoughts to share as follows. In fact, most of my Scrum experiences are scaled Scrum teams.

A Nexus consists of 3-9 Scrum teams which may have different structure and competencies.

Product Backlog items are refined into thinly sliced pieces of functionality and the team likely to do the work should be identified as early as possible.

Appropriate representatives from each Scrum Team meet to discuss and review the refined Product Backlog. They select Product Backlog items for each team.

The representatives select the PBIs based on competencies, dependencies, capacities.

Each Scrum Team then plans its own Sprint, interacting with other teams as appropriate.

Interacting and communicating are very important at this moment.
Each team must negotiate with other team to set the order of the selected PBIs to minimize or remove the dependencies.
In chance there are two dependent PBIs selected by different team due to competencies or capacities. The teams could renegotiate with the Product Owner to refine or to combine the dependent PBIs.

The outcome is a set of Sprint Goals that align with the overarching Nexus Goal, each Scrum Team's Sprint Backlog and a single Nexus Sprint Backlog.

This definition of outcome is very clear. It does not need to explain more.

The Nexus Sprint Backlog makes the Scrum Team's selected Product Backlog items and any dependencies transparent.

Per my experiences, there is indeed a Nexus Sprint Backlog.
The purpose of the Nexus Sprint Backlog is to remind the owner, the Scrum Team, of each Item, and to make any dependencies transparent.

Just for your reference.

> So there does seem to be some selecting of PBIs by the representatives before
> the separate Sprint Planning events. I now suspect that maybe both is true? That
> there is that first "pre-selection" by the representatives, which serves as an
> assumption to build the Nexus Sprint Goal and to start the separate Sprint Planning
> events. But that the "real" planning of the Nexus Sprint Backlog happens in the
> individual team Sprint Planning, which concludes the Nexus Sprint Planning.

Before individual team Sprint Planning, there must be a forecast of PBI's that will serve the Nexus Sprint Goal, and any integration dependencies will need to be addressed. With an agreed Nexus Sprint Goal and "ready" Product Backlog Items, individual team Sprint Planning can take place.

However, there's nothing in the Nexus Guide which says that the Nexus Sprint Backlog represents such a forecast (or pre-selection) of PBI's for individual team Sprint Planning. This would make sense, because in Scrum it is up to individual teams to plan their own Sprint Backlogs...nothing is "pre-selected". Moreover, the Nexus Guide says "A Nexus Sprint Backlog is the composite of all Product Backlog Items from the Sprint Backlogs of the individual Scrum Teams." The conclusion I would thus draw is that the Nexus Sprint Backlog does not (and will not) exist until the teams have planned their individual Sprint Backlogs. During Nexus Sprint Planning, teams go into individual team Sprint Planning equipped with a Nexus Sprint Goal and PBI's that are ready for planning.

> It made me wonder what would happen if Nexus Integration Team Members were *not* firmly
> rooted in the Scrum Teams' work. The risk might be to get some kind of "ivory tower" Nexus
> Integration Team, which is probably an anti-pattern to the values of Scrum.

Bear in mind however that even if Nexus Integration Team members are not also Scrum Team members, they can still perform work on the increment. This might involve integration tasks that cut across multiple Sprint Backlogs.

As always, thanks a lot for your input. It helped my understanding a lot!

Who defines "DONE" in scaled scrum (nexus)?

What do the Scrum and Nexus Guides say about this? Things to consider:

- Might the organization have an input?

- Where a Nexus is involved, which authority is accountable for assuring transparency over integration?

- Who actually does the work when creating a “Done” increment and therefore has an interest in assuring quality and standards?

Is the NIT responsible for creation of Nexus Goal? DoD?

NIT is responsible for DoD which is used by all scrum teams in Nexus. Of course every Scrum Team in Nexus could have its own more strict version of DoD.

I do not think that NIT is responsible for a creation of Nexus Sprint Goal.

Ian Mitchell You sound like a really smart guy but some of your answers are not the way some of the material reads in the Nexus guide. I got stuck on the NEXUS sprint planning as well you speak as if there are definitive ways.

I bought the book, I have the Nexus guide and it specifically says that there is a NEXUS Sprint Planning 1st then teams go do their own sprint planning.  You are saying the reverse of everything I am reading. I have even been watching videos about it. 

Really I just want the CERT my practical implementation will use some of of the NEXUS theory but the reality for me as I stated a a few days ago I will only confuse my teams prescribing 100% to the NEXUS sprint backlog and planning. 

And that's what makes me agile.

I would like to add about when items are picked w.r.t Nexus Sprint Planning and Individual Sprint Planning sessions by each team.

I think my suggestion is to differentiate the context of the word pick. During Nexus Sprint planning the context is to IDENTIFY which teams are best fit to do what PBIs. During individual Scrum planning sessions the context is what items that are identified for that team they can pick for the Current Sprint and INTERACT with other teams to recognize what they cannot do or what more they can/need to do! I guess the below statement summarizes this aspect of my understanding.

"Nexus Sprint Planning continues with each Scrum Team performing their own separate Sprint Planning. The Scrum Teams should continue to share newly found dependencies with other Scrum Teams in the Nexus. "

Correct. The Nexus Sprint Backlog must continue to evolve, indeed not only during Planning but throughout the Sprint. Dependencies between teams are emergent and establishing transparency over them is paramount.

Nexus has one Product Owner, Product Owner attends the Nexus Sprint Planning but at the same time Scrum Guide mentions that Product owner is must in Sprint Planning and Sprint Retrospective.

So how Product Owner can make it possible to must attend the Nexus Sprint Planning, Individual Scrum Teams Sprint planning and Nexus Sprint Retro as well as individual sprint retro's?

Can anyone please clarify?

Teams must collaborate during Sprint Planning so they can manage their dependencies, and that may include access to the PO during that event.

During Sprint Retrospectives, a PO may choose to apportion the time spent with each team so it adequately reflects the portion of time spent working with them during the Sprint.

So how Product Owner can make it possible to must attend the Nexus Sprint Planning, Individual Scrum Teams Sprint planning...

Even with a single Scrum team, the Product Owner (PO) doesn't need to attend the full Sprint Planning event. Once the team has decided on their Sprint Goal and selected the Product Backlog Items they'll work on for the Sprint the Product Owner is free to leave while the team begins tasking out the Sprint Backlog for the first 2-3 days of work. The development team may need to speak with the PO if they realize during tasking that they need to adjust the amount of work they have, but they are also empowered to do the best they can if the PO is unavailable in the moment.

The Nexus Sprint Planning essentially fulfills the first half of the regular Sprint Planning (defining a Nexus Sprint Goal and pulling PBIs into the individual team backlogs.) Then the individual team planning will fulfill the second half of breaking their selected work into tasks.

It would be wise for the PO to make themselves available or connect with individual Scrum teams during their individual planning, especially if one or two teams are struggling or picked up more complicated or less-well defined Product Backlog Items, but if not the team is empowered to do the best they can considering the circumstances.

...and Nexus Sprint Retro as well as individual sprint retro's?

They don't need to be at the individual team Retrospectives. The second part of the Nexus Sprint Retrospective, where the teams break into individual teams and conduct internal team retrospectives, functions as described in the Scrum Guide, which never mandates that the PO be at the Scrum Retrospective (point of fact, the only person the Scrum Guide explicitly mandates should be at the Retrospective is the Scrum Master -- "The Scrum Master participates as a peer team member.." -- for everyone else, the event is an "opportunity.") Clearly, I would encourage the PO to attend one of the individual team Retrospectives, especially if there was a team that clearly needed more support or help during the Sprint, however since issues impacting multiple teams members are raised during Part 1, since the individual teams bring their key concern back in Part 3, and since one of the outputs of the Retrospectives are Product Backlog Items dedicated to team improvement for the upcoming Sprint, there is still a feedback loop that ensures crucial concerns make it back to the Product Owner. Also, since each team has their own Scrum Master who WILL be in their team's Retrospectives, any Scrum Master worth their salt is making sure their individual team's concerns get raised to the PO as soon as possible.

Hi gentlemen.

I would like to add a fun fact. Imagine teams going into their separate sprint planning. They all pull-in work from the common nexus product backlog. I suspect they would have to refresh a lot since multiple teams may go for the same PBI :)

Cheers.

Hi,

with reference to the new version of Scrum Guide: is there any Nexus Giude update planned?

@Hanna, yes there will be a new version of the Nexus Guide early next year.