For scaled scrum ... do you synchronize the end of the sprints?
I'm unclear on whether the various scrum teams have to synchronize their sprints to end on the same dates or not. Is there a single Spint Review where the various team increments are combined and presented to Stakeholders as a single increment for feedback?
Or, do the various spint backlogs get their own sprint end dates and their own Sprint Reviews? I understand that there is a single Product Backlog and a single Product Owner, and that at the start of the sprint the various teams develop their own Sprint Backlogs and their own "Definitions of Done". But is there a single Sprint Goal?
I'm interested in answers as they relate to the PSM 1 Assessment, not just opinions, but Scrum.org writings on this topic.
What does the Nexus Guide have to say about these matters? How important is it for teams working on the same product to synchronise on the integration of a release-quality increment?
We are still awaiting scrum.org answer or clarifications or ... something ;-)
@Olivier as Ian eludes to, the Nexus Guide does not say that they teams must synchronize their Sprint end dates. Do what works best for the teams based on the question he asks "How important is it for teams working on the same product to synchronize on the integration of a release-quality increment" which may depend on what the product is and dependencies of the work.
Now as per the Nexus Guide and Scrum Guide, there is 1 Product Backlog per Product so everyone is working off of a single Product Backlog no matter what their cadence. As per the Nexus Guide:
The result of Nexus Sprint Planning is:
- a Nexus Sprint Goal that aligns with the Product Goal and describes the purpose that will be achieved by the Nexus during the Sprint
- a Sprint Goal for each Scrum Team that aligns with the Nexus Sprint Goal
- a single Nexus Sprint Backlog that represents the work of the Nexus toward the Nexus Sprint Goal and makes cross-team dependencies transparent
- A Sprint Backlog for each Scrum Team, which makes transparent the work they will do in support of the Nexus Sprint Goal
The Nexus Sprint Review replaces individual Scrum team Sprint Reviews. From a practical perspective I would say that the benefits of a common Sprint cadence across the Nexus would the simplification and identification of dependencies across the Nexus, which in turn may support release management.