Skip to main content

Team of Product Owners / Types of Team (from book "Agile Product Management with Scrum: Creating Products that Customers Love" by Roman Pichler)

Last post 06:16 am January 8, 2016 by Ian Mitchell
3 replies
12:07 pm January 7, 2016

Hello everybody,

I am preparing for the PSPO I test and I am reading the suggested book "Agile Product Management with Scrum: Creating Products that Customers Love" by Roman Pichler. In chapter 1, the author proposes two key points:

1. a team of product owners when the product is large, with a product owner "leader"
2. a team organization based on component (horizontal characteristics of the product) or based on feature.

Both claims sound reasonable but they do appear to contrast with some of the principles stated in the Scrum guide (e.g. Product Owner is only one person, Product Backlog contains elements that can be "Done" and released in a functioning product).

Accidentally, I also noted that Roman Pichler seems to lean more on the Scrum Alliance.

I was wondering if anyone would have a comment or a suggestion on how to interpret these two points in preparation to the PSPO I assessment.

Many thanks and kind regards,

Dan


01:24 pm January 7, 2016

Daniele,

This is an excellent question, and it is clear that you are pressing into the more advanced study space.

I ask you to look deeper on something though -- does the Scrum Guide actually require/mandate that each PBI be releasable on it's own?


02:07 pm January 7, 2016

Hello Charles,

thanks for hint! Actually, the Increment (as a selected set of PBI) only must be releasable, but not necessarily each individual PBI.

I will try to ponder better also the first point, but if you have any hint to share, you are more than welcome.

Many thanks and kind regards,

Daniele


06:16 am January 8, 2016

> ...they do appear to contrast with some of the
> principles stated in the Scrum guide (e.g.
> Product Owner is only one person...

Each product must have exactly one Product Owner. However, composite products may exist and this can bring scaling issues. It's reasonable to have a PO who is accountable for the composite product and its value stream, but who then delegates ownership of one or more component products to others.

In this sense there can be said to be a "lead" PO, although it is not a term I approve of as it implies command and contol rather than empowered product ownership. Logically these are all discrete products, including the composite one, and so it is best to think simply in terms of their respective Product Owners.


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.