DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports
Events Video Library
Refcards
Trend Reports

Events

View Events Video Library

Zones

Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks

Last call! Secure your stack and shape the future! Help dev teams across the globe navigate their software supply chain security challenges.

Modernize your data layer. Learn how to design cloud-native database architectures to meet the evolving demands of AI and GenAI workloads.

Releasing software shouldn't be stressful or risky. Learn how to leverage progressive delivery techniques to ensure safer deployments.

Avoid machine learning mistakes and boost model performance! Discover key ML patterns, anti-patterns, data strategies, and more.

Related

  • Feature Owner: The Key to Improving Team Agility and Employee Development
  • Variance: The Heartbeat of Agile Metrics
  • Sprint Retrospective Meeting: How to Bring Value to the Table
  • The Agile Scrum Ceremony Most Talked About but Least Paid Attention To

Trending

  • Vibe Coding With GitHub Copilot: Optimizing API Performance in Fintech Microservices
  • Is Agile Right for Every Project? When To Use It and When To Avoid It
  • Start Coding With Google Cloud Workstations
  • 5 Subtle Indicators Your Development Environment Is Under Siege
  1. DZone
  2. Culture and Methodologies
  3. Agile
  4. Why You Need Only One Product Owner

Why You Need Only One Product Owner

Just because your Scrum scales doesn't mean everything about it does. Having more than one PO in your process will ultimately only slow everyone down.

By 
Roland Flemm user avatar
Roland Flemm
·
Oct. 16, 18 · Opinion
Likes (1)
Comment
Save
Tweet
Share
10.9K Views

Join the DZone community and get the full member experience.

Join For Free

Scrum prescribes one person to the role of Product Owner (PO). Not multiple people, not a committee, just one person:

"The Product Owner is the sole person responsible for managing the Product Backlog." (Scrum Guide)

And when multiple teams work on a single product, the Scrum Guide says:

"Multiple Scrum Teams often work together on the same product. One Product Backlog is used to describe the upcoming work on the product." (Scrum guide)

I encounter many companies that fail to implement this specific Scrum guideline. Apparently, according to most companies, this is one of those things you need to tweak "to make Scrum work in your context."

The Apparent Need for Multiple POs

When companies need to scale up their development effort, they tend to copy complete Scrum teams, including the Product Owner. They soon find out that the PO role does not scale that well by multiplication. As they lose transparency over responsibilities, they try differentiating the PO role in various types of POs such as Feature Owners, Epic Owners, Component Owners and more. They are looking in the right direction to solve their problem but choose the path of complexity instead of simplification: when working with multiple teams on one product, you need exactly one Product Owner. A product is a real product that satisfies a customer need and people want to pay money for it.

In many cases, I see that there is not a problem in handing over the authority and accountability for the whole product to one single person. However, people resist having a single PO because they consider the concept to be unrealistic. They feel having multiple POs and multiple product backlogs is a necessity for various reasons:

  • The Scrum Guide says we need one PO per team, which means we must have multiple POs as we have multiple teams. (This is a myth; one Product Backlog means we need one Product Owner).
  • The domain knowledge for a complex product like ours is too vast for one person to grasp.
  • The workload to produce all user stories is too big and cannot be handled by one person.
  • There are too many meetings in Scrum for a single PO to attend.
  • With multiple POs the PO-availability for teams can be provided at the required level.
  • It is easier to have many POs as it avoids the fight over who should become the one real PO.
  • We come from a situation where we thought we needed one PO per team. Now that they are working here, we cannot just send them away.
  • (This is space to fill in some other silly argument you have heard in your organization.)

Downsides of Having Multiple Po's

Having Many POs Encourages Micromanagement of Teams

In a Product Owner-per-team situation, the PO becomes the person that spells out all the detailed specs (user stories). This setup leads to teams focusing on story readiness, negotiating the level of story detail instead of focusing on value creation. This is a well-known pattern known as the "contract negotiation game." Another effect is the growing absence of domain expertise in the teams. Domain knowledge is concentrated in the PO, which makes the team stick to executing tasks (opposed to solving customer problem), which re-enforces the need for more POs. The PO-per-team setup reduces opportunities for learning and self-organization. I normally suggest making the POs part of the development teams they work with. They will get the opportunity to become multi-skilled development team member with a focus on analysis.

Many POs Requires Coordination and Alignment

The POs decide in a PO team to agree who takes care of which items on the Product Backlog. The customer features are sliced and each PO gets their own sub-scope of the customer value in a Product Backlog. The work is sliced on arbitrary and artificial grounds, creating a coordination need to deliver an integrated product by the end of the sprint. Also, prioritization is decentralized and will lead to local optimization per backlog. This inevitably introduces asynchronous dependencies between teams, as some teams are "full" and cannot do certain work other teams depend upon. Teams don't have a whole product view and lose track of what is customer value. If the coordination need is high between POs, then the Product Backlog has probably not been sliced to optimize for minimal dependencies and the teams are not structured to serve that goal. Having only one PO managing a single Product Backlog for multiple teams creates the transparency required for proper empiricism.

Many POs Bring Unclear Responsibility and Ownership

One PO means that one person is accountable for the ROI on the product under development. With multiple Product Owners, accountability, responsibility, and ownership are obscure. Management has a tough job getting a grip on product development as there is no "single neck to wring." Multiple POs stimulates part-time jobs by adding the PO work to someone's existing workload. This introduces a conflict of interest. With multiple people working part-time on one product the situation does not get any better. Volunteers come to the rescue, thinking "If nobody takes care of this, then I will," and change backlog item priority, add items, or even create their own backlog, creating more complexity. In such cases, I suggest restoring transparency by extending the Definition of Done gradually to include the work described in the additional backlogs or simply merge them into one single Product Backlog.

What If It Fails?

If your PO cannot handle the work involved managing the product:

  • Being a PO is a difficult job and not everybody can do it. Hire someone else, or maybe you can fix it by sending the PO to a proper training.
  • Reduce the number of features (user stories) in the backlog, as they are probably too detailed.
  • Aggregate specs to a low number (3 to 5 stories per team per sprint) to experiment with. 
  • Stimulate "prioritization over clarification." Reduce the level of detail at which the PO is dealing with features by explicitly bringing the clarification responsibility in the team. The PO can help by connecting the team to a stakeholder or customer.
  • Limit the planning horizon to no more than 2 to 3 sprints of work ahead, as preparing more work is likely to result in waste. If you are able to predictably specify your work more than 3 sprints ahead you maybe should not be doing Scrum as your product is not complex enough.
  • Prevent the Product Backlog from spawning by extending the DoD, continuously reducing technical debt with merciless refactoring and strict bug policies.

Conclusion

The PO role is better not scaled by multiplying POs as this has many downsides. I encourage having a single Product Backlog and a single PO being responsible for return-on-investment when developing one product. Having a single Product Owner creates transparency and enables proper empiricism. The concept of a single Product Owner in a scaled environment (multiple teams working on a single product) is challenging if you stick to the idea that the PO has to manage every detail. When scaling, try shifting the PO focus from clarification to prioritization. This will encourage the teams to better understand what needs to be created for the product. This approach is completely in line with backlog management described in the Scrum Guide:

"The Product Owner may do the above work, or have the Development Team do it. However, the Product Owner remains accountable." (Scrum Guide)
scrum Sprint (software development)

Published at DZone with permission of Roland Flemm, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Related

  • Feature Owner: The Key to Improving Team Agility and Employee Development
  • Variance: The Heartbeat of Agile Metrics
  • Sprint Retrospective Meeting: How to Bring Value to the Table
  • The Agile Scrum Ceremony Most Talked About but Least Paid Attention To

Partner Resources

×

Comments

The likes didn't load as expected. Please refresh the page and try again.

ABOUT US

  • About DZone
  • Support and feedback
  • Community research
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Core Program
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 3343 Perimeter Hill Drive
  • Suite 100
  • Nashville, TN 37211
  • support@dzone.com

Let's be friends: