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
Author
Messages
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.