Product Owners are not a myth

Steven Borg brought “ 5 Reasons Why a Product Owner Team Might Be a Good Idea ” to my attention which in turn lead me to read “ Is Scrum a –ism that doesn’t work for real? ”, and for me there seams to be a certain amount of “missing the point” and I wanted to try to find it.

Lets start with a definition of “Product Owner” from the Scrum Guide:

The Product Owner

The Product Owner is responsible for maximizing the value of the product and the work of the Development Team. How this is done may vary widely across organizations, Scrum Teams, and individuals. The Product Owner is the sole person responsible for managing the Product Backlog. Product Backlog management includes:

• Clearly expressing Product Backlog items;
• Ordering the items in the Product Backlog to best achieve goals and missions;
• Ensuring the value of the work the Development Team performs;
• Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next; and,
• Ensuring the Development Team understands items in the Product Backlog to the level needed.

The Product Owner may do the above work, or have the Development Team do it. However, the Product Owner remains accountable.

The Product Owner is one person, not a committee. The Product Owner may represent the desires of a committee in the Product Backlog, but those wanting to change a backlog item’s priority must convince the Product Owner. For the Product Owner to succeed, the entire organization must respect his or her decisions. The Product Owner’s decisions are visible in the content and ordering of the Product Backlog. No one is allowed to tell the Development Team to work from a different set of requirements, and the Development Team isn’t allowed to act on what anyone else says.

- The Scrum Guide

Being a Product Owner is a management role that does not involve managing people, they are instead managing the “what” that the Development Team are building. They don’t actually have to physically maintain the backlog, or even order it. They are however completely responsible for the backlogs content, order and understanding.

Why is everyone finding this so difficult to find?

When I am working with organisation on Scrum Adoptions I find it very easy to identify who the Product Owner should be with more difficulty involved in getting that person to accept that responsibility. I usually let the company lead themselves to the correct understanding of how that should happen as they are the ones that are best placed to figure it out.

We do Scrum but we use a Proxy Product Owner from IT because the Product Owner does not have time to be available for the team so the Proxy makes the decisions for the Product Owner and only gets their input when it is a big decision. Bad ScrumBut – Proxy PO’s never work out

I occasionally end up with a Proxy Product Owner and while this is defiantly a “ScrumBut” that results in the businesses order not being reflected in the backlog it is all too common. While, like all “ScrumBut” this has a negative result, as long as everyone understands the negative result and accepts it transparently then at least we can move on. The organisation will figure out evenly why it is not recommended but sometimes things need to learned rather than told.

Why would you not have a Product Owner team?

I don’t think that any part of Scrum negates the possibility of having a team of people who work for the Product Owner, in fact it positively encourages it. Just because the Scrum Guide does not explicitly say that something is true does not make it false. This is one of the reasons that many non-prescribed things have been stripped out of the Scrum Guide 2011 in the first place.

I can think of many circumstances where you may have both Project Managers and Business Analysts that work for the product Owner and provide some of the extra capacity that they may need because their backlog is too big.

We do Scrum but our Product Owner can’t understand and order the entire backlog because it contains over 900 items so the Product Owner has a team of Business Analysts to help him bring the important ones to surface Good ScrumBut - Although 900 items is too much overhead

My current customer has one product with over 900 items in their backlog. This would be impossible for a Product Owner to fully understand by themselves. They would need minions that can analyse that list and surface the most relevant items for the Product Owners consideration and ordering at the top of the backlog. Does this sound slightly like a Business Analyst roll to anyone else?

Although the Product Owner has accountability and responsibility for the “what” that the team is  creating they will often need help. This help can come in many forms. It may be the Development Team that helps the Product Owner in small organisations, or a more formal dedicated team that helps them at the enterprise level.

How does your Product Owner organise their time?