Skip to main content

Can two teams work on one product backlog?

Last post 01:17 pm January 7, 2020 by Thomas Owens
4 replies
07:24 pm January 6, 2020

I have a scrum team of 7 people working on a product backlog, PO wants to add another team of 6 people to work on the same backlog. We will have 1 PO 1 Product backlog and 2 teams. Does this sound right? 


09:55 pm January 6, 2020

Scaling does come with a cost, so I can't advise whether that is the right decision; but it's a totally valid approach.

And if there is just one product, it is much better to do things this way, rather than arbitrarily split Product Backlog Items across two backlogs, or between two Product Owners.

The two teams will need to co-ordinate between each other. The two Development Teams may come to arrangements about what each team works on, and the Product Owner is probably keen that any such arrangement does not prevent the most valuable items being done first.


10:03 pm January 6, 2020

Does this sound right? 

Are the team members who will now be available self organizing into 2 teams?


10:46 pm January 6, 2020

Consult the PO ask the purpose of adding new team, what value he wants to gain and overall picture.

There must be some roadmap to guide the PO which triggers the addition?

 


01:17 pm January 7, 2020

Assuming that you have one product, you can have multiple teams working on the same Product Backlog. The structure of one Product Owner per product (therefore, also, per Product Backlog) is also correct. Although designed for cases with 3+ teams, both Nexus and LeSS follow a similar scaling approach.

The issue in this case, though, is the impact of adding another team. Adding more people may not have the desired impact, if the intent is to do more work in less time. First, these 6 people will need to be hired and trained - this will take time away from the 7 people currently working on the product. Once onboarded, there is going to be a continuous coordination overhead between the two teams to ensure they are able to work on the same product without "stomping on each other's work". Scaling is a non-trivial problem.


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.