How to Deal With Multiple Scrum Teams on the Same Project?

Introduction

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><p>“Multiple Scrum Teams often work together on the same product. One Product Backlog is used to describe the upcoming work on the product,”</p><p>— the Scrum Guide</p></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><p>“The Product Owner is one person, not a committee.”</p></blockquote>

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

<blockquote><p>“It’s very hard to listen to multiple voices,”</p><p>— Rebecca Jones, Boost Scrum Master for New Zealand’s National Library.</p></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><p>“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,”</p><p>— James Robertson, DigitalNZ Systems Manager.</p></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><p>“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,”</p><p>“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.”</p><p>— product ownership expert Roman Pichler.</p></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><p>“An Area Product Owner specializes in a customer-centric area and acts as Product Owner in relation to the teams for that area,”</p><p>“An Area Product Owner does the same work as a Product Owner but with a more limited, yet still customer-centric, perspective.”</p><p>— LeSS Creators on the official website of the framework.</p></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><p>“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,”</p><p>“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.”</p><p>— the official website of the LeSS framework.</p></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

• https://www.boost.co.nz/blog/2018/04/multiple-product-owners-scrum-case-study
• https://www.romanpichler.com/blog/scaling-the-product-owner/
• https://less.works/resources/about.html
• https://www.scaledagileframework.com/product-owner/