Nexus Sprint Planning for scrum teams working on multiple cadence

I'm curious as to why your teams are on such a different cadence.

Coordinating multiple teams is easiest when all of the teams have the same cadence. The next easiest is when the shorter cadence evenly divides the larger cadence. It's hardest when the cadences do not divide. In your example, the teams will only align every 6 weeks, and this is assuming that the Sprint start and end periods are aligned.

Because you're having trouble coordinating your Nexus Sprint Planning (and probably the Nexus Sprint Review and Nexus Sprint Retrospective, since the rules of Scrum apply), it seems like your current approach is introducing unnecessary overhead. It seems like it would be easier and more effective to eliminate the problem rather than try to coordinate between teams in this way.

I would wish to clarify when should we start the nexus sprint planning for scrum teams working on multiple cadences.

For example, 4 scrum teams of which 2 teams are working on 3 weeks and the other two teams are working 2 weeks cadence.

The following question appears in the Scrum Open Assessment:

The length of a Sprint should be... 

(choose the best answer)

A) Short enough to keep the business risk acceptable to the Product Owner.
B) Short enough to be able to synchronize the development work with other business events.
C) No more than one month.
D) All of these answers are correct.

The correct answer is D.

Why are the teams you refer to observing cadences that appear to synchronize once every six weeks? Might some of them have cause to adjust their Sprint length so synchronization within one month is facilitated?

Ian my bad, I was actually referring to the wrong cadence for multiple scrum teams. I would rephrase it as evenly divisible for instance Team A chooses 4 weeks and Team B and C choose 2 weeks sprint. 

In the case of multiple teams following different cadences,

"Nexus Sprint Planning occurs after the end of the shortest Sprint to enable the Nexus to adjust its plans as new information becomes available."

"Nexus Sprint Planning is complete when each Scrum Team in the Nexus has finished its individual Sprint Planning events."

In alignment with the above two statements, I would like to validate the below assumptions,

1. Is the nexus sprint planning happening every 2 weeks for both the teams and all the individual sprint planning ends which marks the end of nexus sprint planning?

2. Does the individual sprint for all teams start on the same day?

Thanks,

Umar

"Nexus Sprint Planning occurs after the end of the shortest Sprint to enable the Nexus to adjust its plans as new information becomes available."

I believe that statement is inconsistent with the statements presented in the Nexus Guide and the Scrum Guide.

Nexus is a framework for multiple Scrum Teams working together. Individually, each team uses Scrum and follows the roles, events, and artifacts that are defined in the Scrum Guide. Nexus provides an additional layer above this to facilitate the coordination necessary across multiple teams, but it only clarifies or refines and doesn't change Scrum. A good example of this is in Refinement - not only is refinement executed within each Scrum Team, but there's a new Refinement event as part of Nexus. You can also see this in the Sprint Review - the Nexus Sprint Review is a single event for all Scrum Teams, but follows the rules and guidance in the Scrum Guide.

Aligning the Nexus Sprint Planning with the shortest team's cadence doesn't make much sense in this context.

The Nexus's Sprint is defined as the time from the Nexus Sprint Planning to the Nexus Sprint Review and Nexus Sprint Retrospective, where an Integrated Increment is available at the Nexus Sprint Review. The results of the inspection activities of the Nexus Sprint Review and Nexus Sprint Retrospective feed back into the next Nexus Sprint Planning.

Nexus Sprint Planning starts with a planning session across the teams and then team-specific Sprint Planning sessions with collaboration among teams that require it. The output of Nexus Sprint Planning is the Nexus Sprint Goal, a set of team Sprint Goals that align with this goal, a set of Scrum Team Sprint Backlogs, and a Nexus Sprint Backlog that highlights all Product Backlog Items and any other dependencies between the Scrum Team Sprint Backlogs.

If you were to hold this event at the time of the shortest cadence, the team's with the longer cadence would either not get sufficient value (they already have Sprint Backlogs) or would need to modify their Sprint Goals and Sprint Backlogs. However, dictating to a Development Team how they manage their own Sprint Backlog is against the rules defined in the Scrum Guide - the Development Team, exclusively, owns the Sprint Backlog.

I believe I could also make a more fundamental argument that aligning Nexus Sprint Planning and involving all of the teams at such a frequent rate goes against core lean and agile principles around sustainable pace, maximizing work not done, empowering the team, and eliminating waste (extra processes or events, task switching, and management activities are all considered waste).

Instead, I would align the Nexus events with instances when all teams are starting or ending a Sprint. Teams with shorter cadences can have Scrum Team level planning, review, and retrospective events in accordance with the Scrum Guide within the context of their Sprints. The Nexus-wide portions are added when the teams are all aligned. The chosen cadences of the teams should allow for Nexus-wide events to occur at the proper frequency.

All of this said, I do believe that the right thing to do is to simply have all teams on the same cadence. Then, you reduce the waste around planning and coordinating events and accounting for teams with different cadences. The act of managing each team in the Nexus and the Nexus as a whole becomes much simpler, and we want to reduce complexity.