When multiple teams work for the same product they should be working from the same Product Backlog?

Multiple teams building a single product work from a single Product Backlog that defines all of the work to be done on the product. They do not each have their own Product Backlog. Product Backlog Items are not pre-assigned to the teams. The LeSS Product Backlog is the same as in a one-team Scrum environment.

Índice Show

Properties of a good Product Backlog
One Product Owner to rule them all
When more is necessary, LeSS is the answer
Large-scale Scrum frameworks for multiple Product Owners
Conclusions

Properties of a good Product Backlog

A good Product Backlog must:

have estimates for all items,
have finer grained items at the top and coarser grained items further down, and
be prioritized.

Use simple tools for the Product Backlog. We’ve seen LeSS Huge initiatives (with thousands of people) manage the Product Backlog with a simple spreadsheet. Avoid unnecessary and costly complication by using the simplest tools possible for managing the Product Backlog.

Here is a side note regarding tool usage in Scrum and in LeSS. It is common for organizations to look for tools to solve their problems even though tools are rarely the cause of the problem. Avoid solving problems with tools unless you truly, deeply understand the problem and consider a tool to be the right solution for that particular problem.

The Scrum Guide describes the Product Owner as the sole person responsible for managing the Product Backlog. In other words, the Product Owner defines what the development team is supposed to build and in which order.

The “less is more” philosophy certainly applies to Product Owners, but there are many situations when having multiple product owners is unavoidable, and it’s paramount to know how to deal with them.

One Product Owner to rule them all

<blockquote>“Multiple Scrum Teams often work together on the same product. One Product Backlog is used to describe the upcoming work on the product,”— the Scrum Guide</blockquote>

One Product Backlog means one Product Owner, which is why Scrum purists argue that you can’t have multiple Product Owners and Scrum at the same time.

According to the Scrum Guide:

<blockquote>“The Product Owner is one person, not a committee.”</blockquote>

The Scrum Guide is very clear about this because committees are known to reduce transparency and dramatically slow down inspection and adaptation.

<blockquote>“It’s very hard to listen to multiple voices,”— Rebecca Jones, Boost Scrum Master for New Zealand’s National Library.</blockquote>

With multiple Product Owners, accountability becomes an issue. When nobody feels personally accountable for meeting deadlines and accomplishing critical milestones, the product backlog often grows larger and larger with no single neck to wring. What’s more, the presence of multiple Product Owners requires complex coordination and alignment, and even the slightest misalignment of priorities can prevent individual teams from doing work.

However, the real needs of real companies working on real products often take priority over best practices.

<blockquote>“If we had one Product Owner, they would spend all their time being a Product Owner, creating stories, sizing stories, doing refinement. Eventually, they’d become disconnected with the actual business that they were supposed to be the Product Owner for,”— James Robertson, DigitalNZ Systems Manager.</blockquote>

The management of complex products is frequently the shared effort of multiple Product Owners, so it’s important to know how to split product ownership in a way that preserves transparency, aids inspection, improves adaptation, and doesn’t lead to inconsistencies.

When more is necessary, LeSS is the answer

<blockquote>“As long as a product is young and hasn’t reached product-market fit—or is close to achieving it—I recommend having a single person in charge of the product,”“But once the product is becoming more successful and starts growing, once it attracts more features and becomes richer and requires more teams to develop it, a single person can usually no longer manage the product—without being overworked or neglecting some responsibilities.”— product ownership expert Roman Pichler.</blockquote>

For example, a product may have several different streams that require a variety of skillsets, with a Product Owner assigned to each stream. A single team sometimes works on daily updates for multiple products, each of which has its own Product Owner. A web development agency may decide to outsource mobile app developers to work on the same product, creating the need for multiple Product Owners.

Large-scale Scrum frameworks for multiple Product Owners

With multiple development teams, the LeSS Huge framework provides a convenient solution that splits the Product Backlog into multiple Requirement Areas and assigns a different Area Product Owner to each. Requirement Areas are customer-centric categories of Product Backlog items, such as reliability, management, upgrades, continuous integration, protocols, and so on. Area Backlog Items are finer-grained than Product Backlog items, which are more coarse-grained and thus more manageable.

<blockquote>“An Area Product Owner specializes in a customer-centric area and acts as Product Owner in relation to the teams for that area,”“An Area Product Owner does the same work as a Product Owner but with a more limited, yet still customer-centric, perspective.”— LeSS Creators on the official website of the framework.</blockquote>

It’s recommended for one Area Product Owner to work with 2 to 8 Development Teams, which is what the standard version of the LeSS framework recommends. Likewise, it’s recommended for Development Teams to have the option to exchange some stories between them in order to promote the idea of a common Project Backlog.

In addition to the LeSS Huge framework, there’s also the Scaled Agile framework, which works with Product Owners and Team Backlogs instead of Area Product Owners and Area Backlogs, and the Product Manager and the Program Backlog instead of the Product Owner and the Product Backlog.

<blockquote>“Each Product Manager can usually support up to four Product Owners, each of whom can be responsible for the backlog for one or two Agile Teams,”“Successful development is, in part, a game of numbers in the Enterprise. Without the right number of people in the right roles, bottlenecks will severely limit velocity.”— the official website of the LeSS framework.</blockquote>

What the LeSS Huge and Scaled Agile frameworks have in common is that one Project Backlog is assigned to exactly one Product Owner, regardless of what terminology is used. This clear division of roles helps maintain priorities in the company and prevents the risk of conflict between different projects.

Conclusions

When the scope of development is huge, and the management has no other option apart from sustaining multiple development teams, it’s often best to split the Project Backlog into multiple areas and assign exactly one Product Owner to each area.

Resources

Today, I am going to do some myth-busting. The myth is a resistant one: Scrum is a one team framework.

Because of this myth, we see other ideas, like:

Scrum is a framework to manage the work of a team.
When you work with more than one team, you need to use a scaling framework like SAFe, LeSS, Nexus, or Scrum@Scale.

In this article, I’m going to dive into the history of Scrum and show that Scrum has…

The question is: ,,Multiple scrum teams creating the same product must use same sprint start date‘‘

I found this question in a Scrum exam preparation book. The right answer in the book is „false“ but in my opinion „true“ is the right answer. They are creating the same product and have all the Nexus events together. It dosen’t make sense to have different sprint start dates. What do you think?

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!