Multiple scrum teams must use same sprint start date (same product)

The Scrum Guide says very little about multiple teams:

Multiple Scrum Teams often work together on the same product. One Product Backlog is used to describe the upcoming work on the product. A Product Backlog attribute that groups items may then be employed.

When you have two, maybe three teams collaborating on a product, you probably don't need a lot of structure. However, once you get to three and more teams working on one product, frameworks such as Nexus, LeSS, and Scrum@Scale provide additional guidance.

Looking at the most recent Nexus Guide, I don't see anything that says that the teams must have the same Sprint start date and cadence. There are indeed Nexus events aligned across teams, but you could get that regularly if teams have a Sprint duration that is a multiple of each other. Consider a 1-week Sprint, a 2-week Sprint, and a 4-week Sprint. These Sprints would all align every 4 weeks.

I find that teams working on the same product yet have different Sprint start/end dates and cadences adds to the overall complexity. This is further supported by the thinking that one factor for Sprint cadence duration is the frequency of synchronization with stakeholders outside of the Scrum Team. Teams working on one product have many, if not most or all, of the same external stakeholders.

The false answer seems to be the technically "right" answer, considering the Scrum and Nexus guides. However, it doesn't mean it's a practical answer.

Suppose teams observed 2 and 4 week Sprints which aligned every 4th week. Would the answer to the question, as written, then be "true" or "false"? Where does the question come from and is there reason to have confidence in the source?

The question says nothing about Nexus, so why interpret Nexus in that.

Of course you can have one product with several Scrum Teams in different Sprint Lengths. The teams self organize themselved, including Sprint time-boxes. 

Their sprint result may be released immediately after the sprint, but increments do not need to be rolled out immediately, the PO can also gather and release after a certain amount of Sprints or wait until the next team is done and then release the product.

Thanks everyone for your answers.

The question is taken from a German book titled "Scrum Master Exam Preparation" from the publisher Scrumprep.org.

Technically the answer seems to be correct, because nowhere is the opposite described (in the Nexus or Scrum Guide). However, it would most likely not be practical.

What Scrum Master Exam is that book preparing you for?  Be wary of those kind of resources because they can sometime be preparing you for exams that are not recognized or recognized as poor representation of Scrum.  I always suggest that you focus entirely on the Scrum Guide (https://scrumguides.org/index.html) as your source of information as it is the definitive source of information on Scrum. For Nexus here is your definitive source (https://www.scrum.org/resources/scaling-scrum).  If you read something that is not in line with those guides then you may be mislead.  Always go to the actual source for definitions and clarity.  They will usually leave room for interpretation but that is because they are guides not rules.  If you can learn and undestand the premise on which the guide bases it's statements, application is easier.  But as the Scrum Guide says :

Scrum is:

• Lightweight
• Simple to understand
• Difficult to master

The question that was asked at the top is also a question that is on one of the Scrum.org exams and it leaves me very confused.

* Do multiple Scrum Teams working on the same product need to have the same Sprint Start Date? I have to be honest, I'm confused as to what is the right answer based on the various answers by several well-informed people here on Scrum.org. I've read a lot and my answer is still, I have no idea. Would love to know what is the "right" answer.

However, let's say that it is NO. If that is the case, then what would be the answer to this hypothetical question?

* Do multiple Scrum Teams working on the same product need to have the same Sprint Review or Sprint End Date? I tried researching this and I'm still left confused based on some of the comments.



This leads me to the next question that I have seen asked out there on various forums.

* When many Scrum teams are working on the same product, should all of their increments be integrated every Sprint?

My gut reaction is to say that if a work item is not integrated then it can't be considered "done" and therefore can not yet be called an increment. Therefore, I believe the answer should be Yes. "All increments need to be integrated every Sprint, otherwise, it's not an increment."

Any clarification would be helpful. Thank you.

Dose different scrum teams working on the same product and have different sprint backlogs for each team work on the same sprint events? there is a question I find also confusing regarding 

Which statement is correct when four teams are working on a product?

• There is only one Sprint Backlog in each Sprint. (means each team will have separate sprint)
• There are multiple Sprint Backlogs in each Sprint. (means each team will have shared one sprint and events )

Going to try to and provide my opinion to @Vincent Carter and @MOHAMED EL ZAYAT questions together. 

Would love to know what is the "right" answer.

There is no "right" answer, only an answer that is right for your teams.  That is why you have not found any of us giving a definitive answer.  Each Scrum Team is self organizing, self managing so they can determine what works best for them.  The Product Owner is responsible for ordering the Product Backlog in a way that will maximize the work done by the Developers.  If two teams are working on the same Product, then they should be working from the same Product Backlog. Every Sprint has a Sprint Backlog. If you have more than one team working from the same Product Backlog, there will be, by definition, multiple Sprint Backlogs and Developers will work on the Sprint Backlog for their Sprint.  Synchronizing the start Scrum events is not necessary since each Sprint delivers stand alone value.  

From the Scrum Guides section describing the Increment:

An Increment is a concrete stepping stone toward the Product Goal. Each Increment is additive to all prior Increments and thoroughly verified, ensuring that all Increments work together. In order to provide value, the Increment must be usable.

Multiple Increments may be created within a Sprint. 

This from the section that defines Scrum

The Scrum Team turns a selection of the work into an Increment of value during a Sprint.

From section that describes the Developers

Developers are the people in the Scrum Team that are committed to creating any aspect of a usable Increment each Sprint.

Taking all of those statements leads me to believe that every Sprint will have at least one increment of value produced.  So if you have multiple teams working on the same Product, using the same Product Backlog, and creating individual Sprint Backlogs they would all be creating individual increments of value.  There would not be a need for all of the work to be merged in order for an increment to be created.  Integrating all of the increments would create a larger body of value but that is not the purpose of each Sprint. If you are breaking work across the teams so that there is value derived only when all of the work is merged, you are missing the point. 

@Vincent Carter stated this

My gut reaction is to say that if a work item is not integrated then it can't be considered "done" and therefore can not yet be called an increment. Therefore, I believe the answer should be Yes. "All increments need to be integrated every Sprint, otherwise, it's not an increment."

If your organization has a Definition of Done that states this, then it should be followed.  But work is considered "done" when it meets the Definition of Done. If you have a organizational Definition of Done that states this I would assume it is difficult to ever get an increment completed when multiple teams are working on the same increment.  Even if they did share common schedules, it seems like there would always be work in progress and the increment would never be done.  However if your Definition of Done is defined at the team levels, it is possible for many increments to be completed during a single Sprint. 

The events in the Scrum Guide are contained in a single Sprint.  They are meant for a single Scrum Team.  If you want to start combining teams into events, you might want to consider looking at the Nexus Guide for information on how to do so.  

I hope this helps.  But also remember that this is just my opinion and interpretation.  Scrum is a framework and not a process.  In the end it will always come back to what your team, your organization feels is the best solution.

I have a take on the original question I'd like to share.

What MUST you do?

Any time someone suggests that Scrum tells a team they must do something alarm bells go off in my head.

There are indeed some hard and fast rules in Scrum, but it's a framework, not a rigid set of rules you must follow. The term must doesn't seem too Agile if you ask me.

Additional Assumptions

If each team has the same start date, is it not implied that the end dates will be the same as well? Otherwise the start dates will be out of sync after the first Sprint.

So the question then dictates that all teams have the same Sprint length, which seems unreasonable.

One Scrum Team might have 8 developers. Another Scrum team might have 3 developers. I could certainly see a small team deciding to have a shorter sprint length then a longer team.

Pragmatism vs Self-Management?

I think pragmatically it would be beneficial to various parties outside the Scrum Team to have fixed Sprint lengths and fixed Sprint dates. Our minds like structure, repetition and predictability. But as we all know, those aren't the core Scrum Values.

[Image from Scrum.org]

Iteratively Integrating Increments

@Vincent Carter floated this question:

When many Scrum teams are working on the same product, should all of their increments be integrated every Sprint?

I can't find the word 'integrate' anywhere in the Scrum Guide. So I'm not totally clear on what it means to integrate an increment.

The Scrum Guide does say this about the creation of multiple increments, although it does not explicitly describe it in the context of multiple teams:

"Multiple Increments may be created within a Sprint. The sum of the Increments is presented at the Sprint Review thus supporting empiricism."

My guess is summing the Increments is akin to integrating them.

Continuous Delivery of Software is our Highest Goal

If we are Agile software developers, we believe that the continuous delivery of software is our highest goal. At least, that's what the Agile Manifest says.

Shouldn't an Increment, which is what we get when a Product Backlog item meets the Definition of Done, be integrated immediately, and then pushed right into the hands of the stakeholders? Isn't that what Agile software development all about?

The Scrum Guide certainly thinks so, as it states:

"An Increment may be delivered to stakeholders prior to the end of the Sprint. The Sprint Review should never be considered a gate to releasing value."

Why Wait to Integrate?

I'd also say not integrating an Increment will make Sprint Planning difficult for the other teams working on the same project. You don't want a team picking an item of the Product Backlog that's already been completed. And you want the stakeholders to be able to accurately inspect what is done during the Sprint Review. It would seem difficult to do that if all of the Increments were not integrated.

[Image from Scrum.org]

Darcy, I disagree with a couple of your assertions/suggestions.

One Scrum Team might have 8 developers. Another Scrum team might have 3 developers. I could certainly see a small team deciding to have a shorter sprint length then a longer team.

This statement implies a potential correlation between sprint length and team size, which is simply not supported anywhere in the Scrum Guide.   It is incorrect to consider team size as a factor in their ability to produce a working increment, or to adjust sprint lengths based on it.   Limiting risk and increasing inspect/adapt cycles are a couple reasons to opt for shorter sprint lengths, according to the Scrum Guide.

 So the question then dictates that all teams have the same Sprint length, which seems unreasonable.

Why is that unreasonable?  Supporting the same sprint length and cadence for teams helps eliminate lean waste associated with varying schedules, and promotes organizational alignment.

@Timothy wrote: This statement implies a potential correlation between sprint length and team size, which is simply not supported anywhere in the Scrum Guide. It is incorrect to consider team size as a factor in their ability to produce a working increment, or to adjust sprint lengths based on it. 

Corelating vs. Envisioning

I never suggested there was a correlation between sprint length and team size.

I simply asserted that I could envision a scenario where a small team might want a shorter Sprint length. Could you not envision any such scenario?

I could also envision the reverse. I could envision a lot of things, and as a Scum Master, I would encourage the Teams I work with to self-manage and do what's best for the team.

I'm not saying it's a requirement, or that it's demanded, or that it is a must. Just that I could envision a world where it happens. I don't think that's an unreasonable vision.

@ I wrote: So the question then dictates that all teams have the same Sprint length, which seems unreasonable.

@ Timothy wrote: Why is that unreasonable?

Does dictating to a team what the sprint length is going to be support the idea of self-managing teams?

Master Servant Dictator?

I don't think a Scrum Master acting like a dictator is in line with the spirit of the Scrum guide, so from that standpoint, I do feel as though it is unreasonable.

Coach and facilitate? Yes.

Dictate? No.

From where I stand, it seems like the both of you, @Timothy and @Darcy, are saying essentially the same thing. You're just saying it a bit differently.

You both stated that pragmatically there are benefits to equally spaced Sprints, especially to the stakeholders.

But at the same time, some Scrum teams may have interests that run counter to the stakeholders, namely the shorter sprint.

I think that's where a good Product Owner comes in. Convince the Developers of the virtues of a coordinated sprint time. Or if the virtues of staggered sprints are in the organization's best interest, the Product Owner could get the stakeholders to compromise on staggered start times.

Assuming everyone wants what best for the project and what's best for the team, a group of people who share the Scrum Values should be able to balance the interests of all involved.

We seem to have really overcomplicated this one. 



The answer is no, multiple teams do not have to share a sprint timeline. 



If that were a 'must' it would be clearly stated in the scrum guide. 



Remember that nexus is not scrum. They are of course very closely related, but if you're talking about scrum, the nexus guide is not your source of truth, the scrum guide is. 



As others have rightly pointed out, maybe it's a good idea to share sprint timings, but the use of the word 'must' makes the question absolutely false. 

Each team would have to produce at least one Done increment every Sprint, whatever that time-box is for them. This commitment implies a suitable cadence for integration, but beyond that, each team ought to be allowed to do its own thing.

Hence this commitment does not necessarily imply the same Sprint start or end dates, joint events, or any other scaled practices. The preference is to descale the challenge, and to only scale team practices as a last resort.

This is an argument that I have used multiple times when asked this question.  I don't think I have ever posted it here though. 

A Product usually has multiple features in it.  If you had a Product that was being worked on by multiple teams, how often do you think that they would be working on the same feature?  In my experience the intent of multiple teams is to have the ability to deliver multiple features.  So, given that, why would there be a need to integrate the work across multiple teams before releasing?  Can't you release one feature by itself?  Granted there could be instances where work by one team could impact a feature that another team is working on but that should be easy enough for self-managing, self-organizing teams to manage.

Given that each feature can be released independently, why would there be a need to synchronize sprint start/end dates?  

The original question was 

Multiple scrum teams creating the same product must use same sprint start date

Technically this is correct because the very first Sprint that contained work on the Product by either team would be shared by both as it is the beginning of the Product.  But after that initial Sprint starts, there is no reason that every team has to start/end their Sprints in unison.   

To me the term 'integrate an increment' lacks clarity. That's my main problem.

Are the two teams using the same code base? A separate code base?

Agile's highest priority is the continuous delivery of working software. And we can't say the software actually works unless it's integrated. 

I guess we could exclude 'integration' from our Definition of Done, but that would raise an eyebrow.

And we should be continuously integrating. If someone said to me 'we do not continuously integrate our code' I'd really wonder why.

I think that the answer to this question may be also "true" and "false", depending on the situation. If you have to similar team with same task, so ok, they can use the same data for start. But what if one team consists of 5 peoplt and one of 10 ot they have different task? But you need to check it in the in the official manual. 

I teach and coach Scaled Professional Scrum.  Here's some Nexus approach ideas:

I know that the material says you can have different start dates for multiple teams on the same product.  It is better if they are multiples of each other (2/4 weeks but not 3/4 weeks).  Although it seems like there should be a very good reason for this misalignment.

For sprint backlogs, Nexus guide says during sprint planning "A Sprint Backlog for each Scrum Team" is produced.  So 3 teams = 3 sprint backlogs but 1 product backlog.

Code base and increment?  One product 1 integrated increment, not separate code bases or increments.  Use frequent integration and make that part of DOD.

If you break a product into features, it'd be a tradeoff of consistency and tougher integration.  With a huge product this might make sense, but not a first approach.

Try not to make sprint lengths based on the amount of work that you're wanting to complete. That's a project planning approach.   Make a sprint length based how frequently you need to (and can) inspect the increment.  

Trying to keep it short here!