I have some problems with a question I found learning for the Professional Scrum Master 1 exam. The question is:
Multiple scrum teams working on the same project must have the same sprint start date.
I think that multiple teams should start at the same date, but do they really have to? The word "must" really confuses me. Thats why I would choose false, when I had been asked this question.
Is the quoted statement true or false?
In Scrum, there is no definition or ideology of scaling nor syncing Scrum teams - as long as they are all drawing from the same Product Backlog and adhering to the Definition of Done that was set it is irrelevant when they start/finish. So the answer would be FALSE, as is your thinking.
I would recommend reading the Scrum Guide a few times and slamming out Open Assessments of the PSM I, it really helps.
I think that multiple teams should start at the same date. But do they really have to?
Yes and no. You're trying to parse a poor-quality question, and exam practice questions are (by definition) not questions taken directly from the exams. Furthermore, just because a question is in an exam doesn't mean it's got real-world significance.
If you consider a framework such as Nexus, the overall increment (the "Nexus") kicks off and ends at the same time for all teams. If you think about it, this is a hard requirement for ensuring that cross-team work is integrated at the end of each increment.
On the other hand, Nexus doesn't actually require that team Sprints within the Nexus start or stop at the same time. It is certainly strongly implied, as doing so makes integration between teams much easier, but there's nothing in the framework that stops you from having a two-week iteration for one team, and a four-week iteration for another, or having one team end its Sprints on Wednesdays while another team ends theirs on Fridays. However, the framework's design ensures that Scrum teams can't move onto the next iteration until the Nexus is complete, so there would seem to be little value in having different start and end dates. In fact, allowing team cadences to diverge would break the per-iteration feedback loop that is the cornerstone of both Scrum and Nexus!
Furthermore, while scaled agile is largely about reducing dependencies between work streams, they are being scaled precisely because the work needs to be integrated at the end of each iteration. Truly agile organizations will interpret this to mean frequent (if not truly continuous) integration between streams, while less agile organizations will typically fall back on an explicit integration step at the end.
Running Sprints with different cadences inside a Nexus seems like a process smell, and I can't think of a pragmatic reason for it other than work-product dependencies. Such dependencies are inherently anti-patterns, and suggest that the Nexus Team or the Scrum-of-Scrums isn't managing the top-level Product Backlog correctly.
Synchronising sprints is neither required nor is it necessary.
Typically the reasons given for synchronising sprints are:
All of these reasons are indicators of areas in which the team should look to improve.
As an example, the team should be looking to continuously integrate their code. All teams contribute to the integration process and to fixing issues that arise from integration. If this is done as frequently as possible then integration issues are dealt with close to the time they are introduced.
