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

Last post 09:07 am July 23, 2019
by Bouke Bergsma
11 replies
Author
Messages
12:13 pm April 9, 2018

Can someone please suggestion if all the scrum teams should have sprint of same duration (2 weeks or 4 weeks) in a Nexus. How Nexus is handled when sprint length are of varying duration for scrum teams.

12:46 pm April 9, 2018

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?

01:18 pm April 9, 2018

Thanks Thomas Owens

06:00 pm April 9, 2018

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.

06:45 pm April 9, 2018

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.

 

07:56 pm April 9, 2018

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.

 

02:59 pm January 15, 2019

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?

03:44 pm January 15, 2019

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

03:59 pm July 14, 2019

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?

11:36 am July 15, 2019

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.

05:32 am July 23, 2019

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. 

09:07 am July 23, 2019

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!