3

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?

  • Generally, interpreting test questions is out of scope because no one knows what the tester really has in mind or considers to be correct. However, I think the question itself is on topic for PMSE. – Todd A. Jacobs Sep 9 '16 at 21:16
  • The statement is false. If you are taking one of the open assessments, you will receive the correct answers at the end. Do the rules in The Scrum Guide require it? (No.) These questions can be fielded in the forums at scrum.org – Alan Larimer Sep 12 '16 at 22:53
5

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 agree with your logic but not your conclusion. if you have two teams on the same product you really have one big team. Thus they should all be in the same sprint. – Ewan Sep 13 '16 at 0:29
3

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.

2

Synchronising sprints is neither required nor is it necessary.

Typically the reasons given for synchronising sprints are:

  • The teams only integrate their code at the end of sprints
  • Testing in Scrum teams is constrained to work done by the Scrum team
  • The Product Owner does not have sufficient time to attend multiple meetings
  • The approach to source code control depends on synchornisation

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.