One Team, Several Products = One Backlog or Several Backlogs

One product, one backlog. However, it does depend on how you define "product".

There is also a risk of having one team work on multiple products. Their focus is split and it becomes harder to deliver a cohesive value if, over the course of a single Sprint, they are working on multiple products.

Not ideal, and certainly not as Scrum designed, but one strategy that might improve your situation is to dedicate sprints to specific "products" to support focus and reduce waste and context-switching.

Our team currently working with a few products. At the moment we have one Product Backlog that contains different epics - that almost become like mini Product Backlogs. 

Why "almost"? What is impeding the creation and management of backlogs for these products?

However, it does depend on how you define "product".

@Thomas makes a great point. My current organization has multiple epics in a single Product Backlog. Our trick is to make sure those epics are all aligned with what we call a product.  For us, products are more along the lines of value streams than specific product lines.  We actually have multiple "things created from a code base" that spans our value streams. We also have the potential for multiple teams to work from the same Product Backlog. You may want to look at your definition of product and see if there is a better way to envision the work.

If that is not an option I like @Timothy's suggestion. And I recommend that you contemplate @Ian's question. It may not give you an answer that you like but it will definitely provide a lot of reasons for your organization to inspect and adapt. 

Thank you a lot for your comments.

Hi All,

We're about to start Scrum in my company.

There are only 4 developers (one team) and several products, and most of the time every product is developed by one developer (we will work to improve this ASAP).

My idea is to start with only one Product Backlog with items of all the different products, but it will be hard to define the Sprint Goal, and also it will be hard to prioritize.

What is your experience working with one single PB with different products, and taking into account the reality of my team? Is the first time we will work with Scrum in this company, I want to start as soft as possible! hahahaha.

Thank you very much in advance!

Have you thought about the complexity of the products you are working on, the need for empiricism, and whether or not Scrum would be a good fit?

Hi Ian, thanks for your fast reply! :)

I'm new in this company, I need more time to answer your question ;)

That is the structure in this company and we know that starting with Scrum will bring some important changes, maybe some changes in the structure itself.

We believe in Scrum and the decision is to start with it and adapt our reality to Scrum if we find that this will be productive. 

Your "question-answers" are always powerful ;) but, if you want, tell me... we can try to start with a single PB or you think this will be a big mistake?

(oooops, I see a new Ian's question coming.... ;-p )

Scrum requires one PB per product, so if you have one PB for multiple products then you will not be following Scrum. 

Thanks Scott ;) I know this, but some people work this way (one single PB with several products), and I just want to know if in some cases it's an option or not.

As I said, we are planning our start with Scrum and I'm new in this company, once I have more information about the products I will have more data to decide, but yes, I suppose we will start as good as possible, so, we will have one PB for each Product.

Thanks.

we can try to start with a single PB or you think this will be a big mistake?

Two questions, bearing in mind that each product should have its own Product Backlog for transparency:

• What advantage do you see in having one Product Backlog, given you anticipate it would make it harder to define Sprint Goals and to prioritize? 
• You say you want to "start as soft as possible". What difficulties would clear and distinct Product Backlogs expose which you would rather remain hidden?

 I want to start as soft as possible

I suppose we will start as good as possible, so, we will have one PB for each Product.

Those two statements, based upon my experience, indicate that the organization doesn't want to embrace Scrum fully. They want to try some things so that they can pick and choose what they like.  

That is the structure in this company and we know that starting with Scrum will bring some important changes, maybe some changes in the structure itself.

If everyone knows this then why slowly start? Why not jump in with as many changes as possible that further the adoption of Scrum?  In all the cases I know and have experienced where a company tries to ease into Scrum, they never get there.  They don't see the benefits that the consultants or web articles promise and usually end up going back to something that "worked for us before". Companies that have had a modicum to large success started with a large change. 

I said all of that because the product backlog is not your biggest problem. If you do arrange in Scrum Teams, if you do identify and define your products the processes will come together.

Everyone have ignored this statement so far.

There are only 4 developers (one team) and several products, and most of the time every product is developed by one developer (we will work to improve this ASAP).

If everyone "know that starting with Scrum will bring some important changes" how does the organization see 4 developers that each build multiple products be split into Scrum Teams?  How many people do you have that are fulfilling the Product Owner roles? How many people do you have fulfilling the Scrum Master roles?  Are you sure that "we" fully understand Scrum or do they understand some of the terms?

I suggest that you spend some time focusing on what you company calls "products".  I have seen that when people make comments like yours they in fact have multiple features of a few products.  Define your products and identify the Product Owners before you start any other transition.  This will allow the Product Owners to spend time putting together a product roadmap and populate a Product Backlog with work that needs to be done.  Then start transitioning to Scrum by allowing the Developers and Scrum Masters to organize around the various Product Backlogs

 Ian Mitchell :

At this moment developers are not using Scrum but they have a single backlog for all products, that is the reason I wanted to know if it's feasible. As I said, I'm new in this company, I didn't have the opportunity to check this backlog and I don't have enough information of the products. I saw that some people work with Scrum with a single PB with different products and I was just investigating if it was an option. 

Thanks for your time and useful comments!

Daniel Wilhite : 

"Those two statements, based upon my experience, indicate that the organization doesn't want to embrace Scrum fully. They want to try some things so that they can pick and choose what they like.  " --> Not at all, I think I didn't explain it well. For me "as soft as possible" was referred to one single PB if it was an option, I would not asked this (because Scrum is clear about PB) but I saw companies working this way, so it was just curiosity, to know if it was possible.

About your two last paragraphs, I totally agree. Yes, we are just in the beggining, and defining the roles will be difficult too. It's a real challenge. Now it's clear to me, one single PB for all products is not an option.

Thank you very much!

Hi All,

OK, I will have one DEV Team (4 developers) that are always working in several products at the same time (3, for example). So, we will have one PB for each product, but in that sprint with PBI of 3 products, it will be necessary 3 sprint goals, one for each product? If not, it will be impossible to find a single sprint goal that fits all.

Am I right? What is your experience?

Thank you very much again!

Do you see a need of changing organisation structure to form feature teams instead of component teams ?. Having the same org structure may not be fully help the potential of being agile. 

splitting the teams in a way to work on 1 product or value stream can help realising the fullest of scrum benefits. 

Balaji Dhamodaran:

There is only one team of 4 developers, I can't split this... :(

Thanks for your help!

@Joan Moreno i Maurel

Let me try to approach this from a different angle.  You do not have a team of developers at all.  You have 4 individuals working on completely unrelated activities that the organization has put together for the purpose of career and work management.  The following is the first definition for the word "team" from the Merriam-Webster dictionary. 

Definition of team

 (Entry 1 of 3)

1: a number of persons associated together in work or activity: such as

a: a group on one side (as in football or a debate)

b: CREW, GANG

If each of your developers are working on different products and that work can not be linked together, you do not have a team.  The fact that each one works separately means that there is no "number of persons" or "group".  The disassociated work indicates that they do not "associate together in work or activity".

So rather than stating that you have a team of 4 developers that you can not split, you should be stating that you have 4 developers that you can not join together. 

The Scrum framework specifies that every product has its own Product Backlog that satisfies this statement

The Product Backlog is an emergent, ordered list of what is needed to improve the product. It is the single source of work undertaken by the Scrum Team.

From what I can tell you have 4 Scrum Teams made up of:

• One Product Owner shared across 4 products
• One Scrum Master shared across 4 products
• One Developer per product. 

While this configuration can be considered a team, it is not optimal.  But it still can be a Scrum Team since all of the Scrum Roles are being fulfilled. So you could split the 4 Developers, 1 Product Owner, and 1 Scrum Master into four  teams.  At that point the topic of discussion should shift to whether the Scrum framework is adding necessary benefit or if it is adding overhead that isn't needed for such small teams. 

You are trying to fit Scrum into your organization without making changes.  Most often the organization needs to change to accomodate Scrum unless that organization started with the Scrum framework from the beginning. That is why introducing Scrum or any other kind of agile practices are called "agile transformations".  It isn't agile practices that transforms, it is the organizations that have to transform.  Introducing Scrum is going to point a lot of changes in perspective to the way the company operates.  Instead of trying to force the framework to change to meet your organization, change your organization.  Your second post in this thread contained this statement

That is the structure in this company and we know that starting with Scrum will bring some important changes, maybe some changes in the structure itself.

We believe in Scrum and the decision is to start with it and adapt our reality to Scrum if we find that this will be productive. 

Stop fighting the "important changes" and embracing them.  The longer you try to make Scrum fit your current situation, the less benefit you will see and the less people will continue to believe it can bring deliver on your expectations. 

Daniel Wilhite thanks again for your comment :)

I just tell you the reality of the company, I can't change it now, we can't hire more developers (just one more shortly, so it will be a 5 developer's team) or change the developers's skills or knowledge about the different products.

For me it's not an option to dismiss Scrum because of the reality of my team. 

Now they don't use Scrum, they have a unique Backlog for all products and they have a meeting every Monday to check what they are doing and what they will do during the week.

One of the goals is to transfer knowledge so that all developers can work on all products. Scrum can help (Refinement, Planning Meeting) and foster team work (Daily, Review, Retrospective).

We want to improve the way the backlog is managed and start working with Scrum events, I think it will be a good option in this company. We are just starting to think how can we start with Scrum, and I prefer to start and fail than not starting. The CEO is open to change whatever is necessary to make Scrum work in our company, but now I don't have another option than start with this 4 developer's team.

All your comments are very powerful, thank you very much to all again :)

Hi! I have a similar question. I hope you don't mind me adding to this thread. 

My company has a platform that currently supports 4 applications. There are two development teams; one for services and one for the front end (UI). The 4 applications use the same services; however, the front end for the applications are all completely different. We have 2 product owners; 1 has one application and the 2nd has 3 applications. We have one Scrum Master. There is one backlog for all 4 applications (which includes stories for each dev team). 

The issue we are battling at the moment is priority of the backlog, given each application has their own needs and goals. All my training tells me there should be one backlog for each product. I have expressed this to my team. However, I am seeking to pull from other's experiences if such a format has been successfully implemented. If yes, is there guidance on how we might be able to make adjustments to gain success in having a prioritized backlog? If such a format has not been successful on one of your teams, can you provide some examples of failures/struggles that I can take back to our team to help support a position of why this approach of 'one backlog for multiple applications' is likely to result in continued struggles or failure? 

Your input if very much valued. Thanks in advance. 

Transparency. It's proving very difficult for a Product Owner to account for and maximize product value without a clear Product Backlog.

One product should have one Product Backlog with one clear owner. Why obfuscate things with a different arrangement?

Thanks for the response, Ian Mitchell. I agree with you 100%. I was asked to find ways to make this work, and I'm simply not finding any suggestions/options. I suspect the reason I am hitting dead ends or not finding supporters for such a model is because it simply doesn't work or perceived benefits were never realized by those that may have tried in the past. 

How about doing one product at a time: a while (maybe a few months) product 1, then some time product 2, and so on?



This way you'll always be focused on 1 product, each Product Backlog contains 1 product, and you'll have 1 product owner and 1 set of stakeholders at a time.

Think of the dependencies within the org.

How does one team coordinate work with the other teams?

Hows does each team know what is next in priority?

How does one team prioritize a request coming in from another team against their own priorities?