Are sprint length for all the scrum teams in a Nexus of same duration?

In Nexus, consider the following things:

• A "Done" increment is delivered after every Sprint. Each of the teams in a Nexus contribute to this Done increment.
• The output of a Nexus Sprint Planning is a Nexus Sprint Backlog that each of the teams uses for Sprint Planning.
• The Nexus Sprint Goal is the sum of Sprint Goals across each of the individual Scrum Teams for the Sprint.
• The Nexus Sprint Review replaces the Sprint Reviews of individual Scrum Teams.
• There is synchronization between Nexus Sprint Retrospectives that involve the teams coming together, then individually conducting a retrospective event, and then coming together once more.

If teams have different Sprint lengths, how can you achieve these? For example, if you have two teams on a 2 week Sprint cadence and one on a 4 week cadence, what happens to the Nexus Sprint Goals when two teams have completed their Sprint and one is still working? How can all teams produce a Done increment and have a review of their work? What happens when you interrupt a team on a 4 week cadence for a Retrospective for the 2 teams on a 2 week cadence?

Thanks Thomas Owens

if you have two teams on a 2 week Sprint cadence and one on a 4 week cadence, what happens to the Nexus Sprint Goals when two teams have completed their Sprint and one is still working? How can all teams produce a Done increment and have a review of their work? What happens when you interrupt a team on a 4 week cadence for a Retrospective for the 2 teams on a 2 week cadence?

There's nothing to stop teams from observing their own Sprint cadence, as long as it is exactly divisible into the Nexus Sprint cadence. Pages 105-107 of the Nexus Framework book address this scenario. Two and four weeks respectively would be possible, three and four would not.

A team observing a two week cadence may plan its own Sprint Goals, which would articulate to the Nexus Sprint Goal and the production of an integrated increment after four weeks.

This technique can help teams manage risk by providing empirical evidence of progress at an earlier juncture. For example two teams might manage their dependencies by sharing an asset in alternate two-week Sprints so a four-week Nexus Sprint Goal might be met.

There's nothing to stop teams from observing their own Sprint cadence, as long as it is exactly divisible into the Nexus Sprint cadence. Pages 105-107 of the Nexus Framework book address this scenario. Two and four weeks respectively would be possible, three and four would not.

There's definitely nothing preventing this, but it does add overhead. If the cadences are the same, then it's very clear how and when to manage dependencies and interactions between teams. If the cadences are different, it requires more sophistication on the part of the teams, including the Nexus Integration Team. It's not something I would recommend to an organization new to Scrum or Nexus. However, if the teams were well versed in Scrum or had spent some time in Nexus and think that it can help them, then it seems to be something that can be done.

There's definitely nothing preventing this, but it does add overhead. If the cadences are the same, then it's very clear how and when to manage dependencies and interactions between teams. If the cadences are different, it requires more sophistication on the part of the teams, including the Nexus Integration Team.

The best means of assuring transparency is by delivering increments of release quality as often as is practicable. The continuous integration of work is instrumental to this capability. If teams don't provide release-quality work by the end of a Sprint, then process overhead and sophistication might be resorted to in an attempt to compensate.

Hence if a team observes (say) a two-week Sprint within a four-week Nexus Sprint, then that two-week Sprint must also yield an integrated and potentially releasable increment.

It's not something I would recommend to an organization new to Scrum or Nexus. However, if the teams were well versed in Scrum or had spent some time in Nexus and think that it can help them, then it seems to be something that can be done.

This arrangement ought to be made only by exception. However, it's the danger of teams losing focus on the agreed Nexus Sprint Goal (in order to meet subordinate Sprint Goals) which can be seen as the principal risk.

In case of a two week Sprint in a four week Nexus Sprint, would the "two week team" have a regular Sprint Review for that team only?

The other teams in the Nexus might have an interest in attending the Review as stakeholders.

In case of a two week Sprint in a four week Nexus Sprint, would the "two week team" have a regular Sprint Review for that team only?

Has anyone have an answer for this? Does this mean that we individual sprint teams can do their sprint review instead if the nexus sprint review for the first 2 week cycle?

In case of a two week Sprint in a four week Nexus Sprint, would the "two week team" have a regular Sprint Review for that team only?

Has anyone have an answer for this? Does this mean that we individual sprint teams can do their sprint review instead if the nexus sprint review for the first 2 week cycle?

Questions like this are why it's incredibly difficult to synchronize teams on different cadences, and it gets more difficult if the cadences are not divisible or if some teams is using a continuous flow model and other teams are on a cadence.

Ian Mitchell brings up a point - if the rest of the Nexus is on a 4 week Sprint cadence, but one team is on a 2 week Sprint cadence, you may want representatives from the other teams at the 2 week Sprint Review. However, this would add a disruption to the teams on the 4 week cadence - at least a subset of the team would have to add an event to support the team that is different and account for this in Sprint Planning.

Personally, I question the value of having Sprint Reviews that aren't across all of the teams working on a shared Product Backlog in any scaled framework. Of the major scaled frameworks, Nexus replaces the Sprint Review with a Nexus Sprint Review that includes all teams, LeSS moves the Sprint Review to a cross-team event, SAFe has Iteration Reviews but only (at least in the versions I'm most familiar with) the cross-team Solution and System Demos are the required events and not the individual team Iteration Reviews. Of the major frameworks, only Scrum@Scale maintains individual team reviews when working on a multi-team effort.

As a general rule, I would always encourage an organization to start with a common, shared cadence, at least at first. This will let everyone focus on building up good habits within and across the team boundaries. Before moving to differing cadences, make sure that there's a real problem to solve and understand what the trade-offs of this one solution are. I would be highly suspect if it's the only solution, or even the best solution, but I would need to take a good look at the problem and the organization - it's definitely a solution that can be on the table.

Thanks for that thorough insight Thomas. I think I'll just suggest to the management to have a standard cadence for all the scrum teams to avoid unnecessary complexity. 

I think I'll just suggest to the management to have a standard cadence for all the scrum teams to avoid unnecessary complexity.

Have you considered that the management might not be the best place for the accountability for the Sprint cadence?

If the sprint length is now in question and management is worried about it in some way, maybe this is an opportunity for the Scrum Master to discuss servant-leadership, trust and self-organization with the management, and to coach the development organization to empirically evolve a proper cadence.

Good luck!

Sander Dur  In case of a two week Sprint in a four week Nexus Sprint, would the "two week team" have a regular Sprint Review for that team only?

Ian Mitchell  The other teams in the Nexus might have an interest in attending the Review as stakeholders.

Is there an official response to this question?

What about other Nexus events such as Nexus Sprint Planning? Page 105 of the Nexus Framework book it reads : "Nexus Sprint Planning occurs after the end of the shortest Sprint to enable the Nexus to adjust its plans as new information becomes available." It gives an example in figure 7-4.

• Team 1 is 4 weeks Sprint
• Team 2 is 2 weeks Sprint
• Team 3 is 1 week Sprint

So this means that Team 1 will go through 4 Nexus Sprint Plannings within one Sprint because of Team 3? The Nexus Goal might be changed 3 times before Team 1 can complete its sprint? Also the NIT would have to secure an integrated and potentially releasable increment every week? I'm assuming that Team 3 is the only one performing their own separate Sprint Planning as part of that Nexus Sprint Planning.

Am I getting something wrong here?

I'm working with several Teams that have different Sprint lengths:

- 4 Teams that use 2 week Sprints

- 1 Team that uses a 4 week Sprint.

I can't decrease the Sprint length of the 4W Sprint Team because due to the complexity of the developed software, The fastest user stories are done at the end of the 3rd week or the beginning of the 4th week. Rest of the week the team helps with testing, does bug fixes or refactoring to remove technical debt.

I use the 4w Team as the backbone/core with which all the other Teams have to synchronize:

- Nexus Sprint Goal is build on the 4w Team Sprint Goal

- The 2w Teams have to prepare two sequential Sprints with the focus on Nexus Sprint Goal

- Members of the 2w Teams attend the 4wTeam meetings as stakeholders

- The NIT Team create every 2 weeks an integrated increment, BUT every 4 weeks a shippable increment.



It's not perfect, but it works quiet well.

Page 105 of the Nexus Framework book it reads...

I know that the Nexus Framework book is recommended by Scrum.org as a Nexus 'case study', but isn't the 11-page Nexus Guide sufficient?

Perhaps it is just me that finds the use of "framework" and "page 105" amusing?

I know that the Nexus Framework book is recommended by Scrum.org as a Nexus 'case study', but isn't the 11-page Nexus Guide sufficient?

Perhaps it is just me that finds the use of "framework" and "page 105" amusing?

Honestly, I found that the Nexus book was incredibly helpful to me gaining a practical understanding of Nexus. Plus, the book was written by the Nexus Steward for Scrum.org so it keeps in line with the Framework and is not just a person's interpretation. 

René Gysenbergs  I use the 4w Team as the backbone/core with which all the other Teams have to synchronize

I guess it all comes down to this single question: what is the Nexus Sprint length when Scrum Teams have different Sprint lengths? The longest or the shortest? The Nexus Guide talks only about "the Sprint" so my guess is there is only one Nexus Sprint for all Scrum Teams.

René Gysenbergs's answer is the longest when the Nexus Book adresses the shortest. Any other thoughts on the subject? 

Is the Nexus Framework book required in order to pass the SPS exam, or is all the freely available material that is linked to Nexus on this site sufficient? 

The material on this site is sufficient, it's what I used to prepare for my exam. That and a bit of Scrum experience, I would say.

The material on this site is sufficient, it's what I used to prepare for my exam. That and a bit of Scrum experience, I would say.

Thank you Henri