Sprint length in Nexus

Let me explain you with an example:

Let us assume there is a nexus with 3 Teams T1, T2, T3.

Nexus Sprint Length: 4 weeks
T1 Sprint Length : 4 weeks; # of T1 Sprints within Nexus Sprint: 1
T2 Sprint length: 2 weeks; # of T2 Sprints within Nexus Sprint: 2
T3 Sprint Length: 1 week; #of T3 Sprints within Nexus Sprint: 4

So, although T1/T2/T3 had different sprint lengths they all gets synchronised at the end of each Nexus Sprint.

> As I understand that all scrum teams part of
> nexus do not have to have same sprint length

I think it's more a case that each team *should* have the same sprint length, in order to avoid the inefficiencies you describe.

One of the best things about Nexus when compared to SAFe & LeSS is :
Nexus is less prescriptive.

There are n+1 number of ways to solve the inefficiencies, if any
but definitely not by making it prescriptive.

Hi Syed,
May I please ask if your explanation is based on real life example or understanding of Nexus framework?

The way you have put it, it would mean 2 Sprint planning for T2 and 4 for T3 while T1 has only 1. Not sure as Nexus guide says that Nexus spring planning does not end until individual Sprint planning of T1, T2 and T3 end. Also, there is no individual Sprint review as it is replaced by Nexus review. That would mean that T2 or T3 will finish their sprints and jump to Sprint retrospective directly without a review. Is it really like that? I am now more confused.

Hi Kamal,

It is based on my discussions on Nexus Framework in various blogs/forums and real life implementation of other Scaled Agile frameworks, but not Nexus (not sure whether so far it got fully implemented elsewhere).

Nexus Sprint and Team Sprint(s) are entirely two different things.
Nexus Sprint Planning is like "Release Planning in SAFe" and of course a lot less prescriptive at the same time, including that no sprint cadence (all teams must have same sprint length of 2 weeks in SAFe) is needed.

If you are not having any idea about SAFe, then I can explain you how it could be implemented in detail in Nexus exactly based on your scenario or a hypothetical one.

Hi Syed,
As you wrote, all teams have same sprint length of 2 weeks under SAFe and so I don't think that scenario we had applies there.

I am still not clear when Nexus Sprint planning will be over when T1 team has a sprint length of 4 weeks, T2 has for 2 weeks and T3 has for 1 week. When T1's 1st planning gets over, it has not covered other 3 weeks of work and so cannot provide all the input to Nexus sprint planning which can be completed only after all teams have finished their planning.

Further, as there is no Sprint review at Nexus level after 1 week, will T1 jump to its retrospective without having any sprint review? Same goes true for T2 after 2 weeks?

I hope that someone who has a practical experience of Nexus where teams had different sprint length can help us understand the scenario better otherwise all teams having same sprint lengths is a better approach to avoid hitting these issues.

Another issue with different length of sprints of scrum teams within Nexus. When will Nexus Sprint Review be held? Per Nexus guide, it is to be held at the end of the Sprint. As T1, T2 and T3 in the example quoted will finish their own sprints at different times, will Nexus Sprint review be held only when longest sprint is over?
I am just wondering if each team has to have same length of sprint for Nexus to align with Nexus Sprint planning and Nexus Sprint review but within it, they can have multiple shorter scrum sprints.

Nexus Guide specifically states that Nexus Sprint Review replaces individual Scrum Team Sprint Reviews (all?). With that being said it's hard to imagine how individual teams would have shorter sprints:

- Without a sprint review? That would be against the Scrum Guide.
- With a separate/internal review? I'm not very convinced to that as well.

"A Nexus Sprint Review replaces individual Scrum Team Sprint Reviews, because the entire Integrated Increment is the focus for capturing feedback from stakeholders."

First of all it is exceptional to have different sprint lengths if every team can keep to the same rhythm it is ideal. In the end what is important to review is the integrated product increment from a user's perspective. Why would there be a different sprint rhythm? One I can think of is maybe a team produces some sort of interface where other feature's are user's/consumers but their use contributes to the overall increment. Maybe a service or an administrative workflow. Maybe the product is operational and these teams have things that need to go to prod quicker but still need to be part of the new increment. Individual teams can have individual reviews if it helps with their and the overall success/value of the increment. I would not do different length sprints just because a team wants to, everyone needs to know, understand and contribute to the bigger picture or it all falls apart.

I have also seen different sprint lengths in larger SAFe implementations. My team was the one with the different lengths we performed a 4 week sprint while every one else performed two week sprints. Then there was an incremented release review which was placed into production after 4 weeks/sprints.

Interesting, how did the Sprint Review look like for the teams having 2 week sprints? Were stakeholders invited and did they give meaningful feedback on the (partial from the scaled perspective) increment?

I second Mark Troyan's opinion.
I can see that some teams in the Nexus could be working 'off Nexus' or just working at a different pace and not need to match the cadence of others.
Having said that, it would be a logistical nightmare to have different sprint lengths at large.

I can imagine a team working totally off-Nexus for a couple of sprints (totally off-Nexus meaning having no common events with the other teams and no dependencies in PBIs)... however I'm interested how in practice such team would deliver a potentially releasable increment that meets the Definition of Done (or actually both DoDs). Not saying it's impossible however the work pulled into the sprint would have to be practically fully isolated from the rest of the product and there is never 100% guarantee that a dependency will not emerge in the middle of the Nexus sprint.

Apart from the above. In the example Syed Shabid Ali brought up one could ask - are teams #2 and #3 actually working as part of Nexus? Do they pull a mix of isolated PBIs and PBIs with dependencies into their sprint? If so - how to they present the latter ones on their individual sprint review - as not (yet) meeting the Nexus DoD? It might not be possible to integrate the work in the middle of team's #1 sprint thus the PBI would not meet the Nexus DoD.

Nexus Sprint Length: 4 weeks
T1 Sprint Length : 4 weeks; # of T1 Sprints within Nexus Sprint: 1
T2 Sprint length: 2 weeks; # of T2 Sprints within Nexus Sprint: 2
T3 Sprint Length: 1 week; #of T3 Sprints within Nexus Sprint: 4