Sprint length in Nexus

How important do you think it is for Scrum Teams — regardless of whatever other Sprint time-boxes they might observe — to agree on a common Sprint time-box for Nexus purposes?

In Nexus says, Different development teams working on the same Product can have different Sprint length. 

Can you please cite this source? I reviewed the Nexus Guide to see if there was an update that I was unaware of, but I could not find a mention of anything about the Sprint length across teams in the Nexus. However, based on some of the wording in the guide, I believe the intention is that all teams in the Nexus Guide have the same Sprint cadence.

Nexua Team consists of 3 teams A, B, C. 

Team A starts sprint 1st October and ends 15th October, Team B starts sprint 5th and ends 12th October, and Team C starts 1st and ends 30th October.

When should be the Review meeting? When should be ready integrated potentially releaseable increment. Thanks. 

Alignment of teams is easiest if all teams have the same cadence, start dates, and end dates. This makes placing the Nexus events trivial. The next easiest alignment is when Sprints lengths are all multiples of each other and align on the longest Sprint. The Nexus events align with the longest Sprint, and teams with shorter cadences would have their events on their cadence. A situation such as you describe with differing cadences and start dates is extremely difficult.

My personal take is that trying to figure out this alignment is wasteful. Align your Sprints and make this overhead go away. Then, focus on the set of other problems that come with aligning multiple teams.

@Thomas, 

I was able to find a whitepaper that mentions this.

https://www.scrum.org/resources/introduction-nexus-framework

A Nexus works within the boundaries of a Sprint(30 days or less), as in Scrum. If absolutely necessary, teams can work on different Sprint lengths, but there must be a common denominator. Teams must deliver into the increment at least at the end of each of their Sprints.

I agree with your take that trying to establish different Sprint cadences for the Nexus would likely result in more waste than anything. 

Thanks for that, Tony. I wonder if that's still considered correct - it's now 3 years old and is not included in the most recent revision of the Nexus Guide. It definitely makes sense, but I would expect this type of rule of the game to be in the Guide and not just a whitepaper.

Good point, I don't recall the guide specify Sprint length just that there's Nexus events and increments that need delivered. 

This statement does seem to have the caveat that each team must deliver an increment even if their cadences do not match...I wouldn't think this approach would typically be desirable.

Perhaps there's rare occasions where for example...2 of the 3 teams are on 2 week Sprints and the 3rd is on 1 week or 1 month so they at least equal out. I don't know what type scenario would benefit from that approach though. 

Thanks Tony for citing the source and Thomas for elaborating on sprint cadence. 

I would like to add a few more points in this regard. 

First of all, the latest version of the Nexus Guide does not mention the different sprint lengths and rightly so. What I also found peculiar and most important is the following statement, perhaps the soul of Nexus in the Nexus Guide

The difference is that more attention is paid to dependencies and interoperation between Scrum Teams, delivering at least one “Done” Integrated Increment every Sprint.

The word interoperation is the backbone of Nexus, hence having the same sprint lengths along with start and finish dates is critical in this manner. The newly added role, Nexus Integration Team is also accountable for ensuring at least one "Done" integrated increment is produced at least once every sprint. In my opinion, it is critical that the development teams operate with the mindset that the entire product team needs to provide "Done" integrated increment/s, which will be reviewed in the Nexus Sprint Review.  In simple words, the review is of "Done" integrated increment/s and not of individual Dev Teams' delivered increments (which may not be a part of "done" integrated increments yet). 

In addition, dependencies in delivering integrated increments need to be understood, resolved and addressed. For that, Nexus mandates Refinement as an event. The Nexus integration team is responsible for coaching and guiding individual scrum teams in acquire, implement, and learn the practices and tools that help interoperation and minimizing dependencies. They are also responsible for coaching the individual Scrum Teams on the necessary development, infrastructural, or architectural standards required by the organization to ensure the development of quality Integrated Increments.

Importantly,

If their primary responsibility is satisfied, Nexus Integration Team Members may also work as Development Team members in one or more Scrum Teams.

That implies (and backed by Nexus guide), the Nexus Integration Team members' primary responsibility is towards the Nexus (in ensuring delivery of Done integrated increment), and maybe not so much towards individual team's events, goals or timelines. In fact, individual teams draw their goals, timelines, and events in line with the Nexus.  

I have seen this conflict in this matter, especially in organizations that are mistaking Nexus as Scrum of Scrums. Perhaps, you would like to inspect that aspect and of dependencies and interoperation.  

Thanks