Single Dev team working on multiple product backlogs (Products)

Question

We have one Dev Team (Approx 20 Team members) currently working on 5 products with 5 product owners (one for each product). We are struggling with story prioritization between different products and lots of meetings for the same.

Below are the two options we are looking at:

1. Merging product backlogs to a single product backlog

So that team can pull stories from one product backlog to sprint backlog. (And does not have to bother about priorities anymore). But a single product backlog maybe too huge and unmanageable.

2. Separating the team into 5 teams for each product

But this is not currently possible as we have resources specialized it a particular skillet and needs to be shared across the products.

Any suggestions?

Answer 1

I would suggest a third option.

Form teams around the products that generate the most work. Then have the remaining developers work on teams that cover the remaining products.

Something like:

Team 1 - Product 1

Team 2 - Product 2

Team 3 - Product 3, 4, 5

Hopefully this will reduce the struggle with story prioritisation (although not completely eliminate it).

The most important thing is to identify what you want to gain by the new organisational structure and how you intend to measure success.

Get some suitable metrics in place, try the new structure and see if the metrics get better or worse. Then inspect and adapt your approach.

Answer 2

This is a common problem and one that can be solved by discipline and team work.

5 Products seams like a lot for 20 people, and hopefully some of that work is similar and you can include it together. I would encourage the group into a smaller number of teams of 6+-3 and have them choose how best to meet the work.

If you have a self organising set of teams they will be able to figure out how to cross train enough that you will not have the need of so many specialists. Have a look at the Scrum Guide (http://www.scrumguides.org/) and follow the guiding principals in there.

Answer 3

I'll make some assumptions first:

1. The products are loosely related - e.g. if your company produces HR software, the products may be Timesheet, Training, Performance Management etc...
2. There is a certain amount of shared code between the products e.g. login, logging, deployment etc...
3. It is possible to have smaller teams that would have the skills necessary to ship product features.
4. The Product Owners are able to understand the business value of a product feature and negotiate between themselves on priority.

In this case I would...

1. Divide into 3 teams of 6/7 - this is enough people with the skills to get significant features done.
2. Have the 3 teams "own" 1 or 2 of the products - this is so that the team can really understand and contribute to the longer term vision of the products, and ensure that technical backlog items are prioritised appropriately against the product value.
3. Have a backlog for each team - that the product owner(s) and team own.
4. Have an explicit method that the product owners use to prioritise features - e.g. business value, WSJF, Kano etc... Agreeing this and writing it down may help stop arguments over the approach
5. Have the 3 teams co-ordinate changes to the shared code - maybe an Inner Source type approach.
6. Have a coach help the team and stakeholders through the change.

Answer 4

I have a couple of things to point out, the tasks priorities are not responsibility of the development team at all, this is something that is managed by the PO for many reasons, but lets not discuss about that.

As you don't have a single PO this is transformed in a fight of interests. If there is no common goal between them every PO will want their US to be done ASAP because is the highest priority for them (and this is totally understandable).

So, if you want to keep one single team for all this products you will need a PO that works as single point of contact for the Dev team, a single backlog for them and then you can try to make sprint goals focused on single products so the dev team does not have to change their "environment" in the middle of the sprint (but this is a bonus point, not mandatory).

The main thing is if it is possible to have this single PO to manage this single backlog, at the end its the same as if your current 5 POs becomes stakeholders, they will ask for what they want, and this single PO will put those thing in order. Based on what ? could be company need, if there are blocking issues or it could go as easy as money ... who is the one that is paying the most and thats the one you will attend first.

In resume, remove the responsibility of picking the task to be developed off the team, it could be by this single PO approach, by a forum between the PO where they manage the single product backlog all together. And those are my 2 propositions.

There are too many factors in place, the company, the POs shared vision and needs, the reason why there is 1 single team that is managing all this.. etc.

We are currently working with one single team for multiple products as well and we have just one PO and a single product backlog and things goes smoothly.

Hope this helps! Any doubt just tell me!

Answer 5

Too many fronts open maybe? Take a step back to revisit your companies goals, consider lowering expectations and re-organise the teams accordingly. If you postpone a product and do 4 products instead of 5 is not the end of the world. This will give you a good boost in the other products. Be smart and pick your battles. You don't need to fight every battle to win a war.