Product Ownership and ‘Overloaded’ Product Owners

In this blog post I show that doing Scrum with an overloaded Product Owner may require two people. This has been done (in practice) for years, and I want you to know that it’s not a violation of Scrum — there is no need to apologize for it… 🙂

Here are some standard definitions, focusing on the Product Owner role.

First, the defining characteristic of the Product Owner, as we find in the Scrum Guide: The Product Owner is accountable for maximizing the value of the Product and the work of the Scrum Team. This definition is about maximizing the value of two different things, and I’d like to investigate and expand this definition in a couple of ways… this expansion is also based on the Scrum Guide.

First, from the Scrum Team’s perspective…

• A Scrum Team is a self-organized group of people (called Team Members) who play the roles of Product Owner, ScrumMaster, and Developer.
  • Only one Team Member may play the Product Owner role.
  • The Team Member playing the ScrumMaster role may not also play the Product Owner role.
  • Any Team Member may play the Developer Role.
• The Scrum Team (including the Team’s Product Owner) is constantly Refining the Team’s Backlog to make the Items ‘at the front’ Ready for Planning.
• The Team’s Product owner is accountable for the prioritization of the Team’s Backlog in order to maximize the value of the work of the Team.

Second, from the Product’s perspective…

• There is a single Product Owner who works with the Product’s Stakeholders to produce and prioritize the Product’s Backlog, which is a list of features, functions, requirements, enhancements, and fixes that the Stakeholders want added to the product.
• Every Sprint, the Product Owner reviews the Sprint’s Product Increment with the Stakeholders and modifies the Product’s Backlog to contain the most current and appropriate Items based on their feedback.
• The Product’s Product Owner is accountable for the prioritization of the Product’s Backlog in order to maximize the value of the Product.

Now that we have the definitions, let’s see what happens when we put together a Team…

First, let’s look at the simplest case, a single Scrum Team (co-located with its Stakeholders) that is working on a single Product. In this case these two definitions of the Product Owner can coincide; that is, the Team’s Product Owner and the Product’s Product Owner are the same person, as we see here…

This is standard Scrum as we learn it. The Product’s Backlog and the Team’s Backlog are actually the same Backlog, the Team’s Product Owner and the Product’s Product Owner are actually the same person (simply called the Product Owner), and it’s all pretty straightforward. But…

What happens when we stretch-out this Team?

What happens when the Team and the Stakeholders aren’t co-located? or even close? What if the Team is in Bangalore, India, and the Client/Stakeholders are in Washington, DC? Usually, of course, we’ll make sure that there is a Product Owner with the Client/Stakeholders in DC.

Let’s say that you are this Product Owner. By default, you are also the Team’s Product Owner. What does this mean?

• You are physically located in Washington, DC, and
• You are a member of the Bangalore Scrum Team who:
  1. is the only Team Member who is held accountable for the value of the Team’s work, and
  2. works with the other Team Members to Refine the Team’s Backlog.

Because you are in DC, and your Team is in Bangalore, you are being terribly stretched, and are most probably overloaded. To handle this overload, you probably get some help doing these things from somebody who is actually in Bangalore, co-located with the Team. You are way too overloaded — there are not enough hours in the day — for you to do it all yourself. The odds are that your relationship with the Bangalore Team is something like this:

• you may speak to the whole Team once in a while, but on a daily basis you stay ‘in the loop’ by talking to one Team Member (I’ll call him/her your Proxy) to figure out what is going on and answer questions,
• when Team Members have “Product Owner questions”, they first ask your Proxy and, if that doesn’t work, they send you an email, and
• you answer their questions about the Product via e-mail on a daily basis.

In fact, it’s often the case that this kind of relationship is what’s required by contract, right?

This is not a bad thing — it’s the way things usually work. But you are not this Team’s Product Owner. In fact, you’re not even a member of the Team; you’re not involved in their daily self-organization — a fundamental part of being a Scrum Team Member (Scrum Teams are self-organizing, remember?).

If this is what’s going on, your Proxy is actually the Team’s Product Owner. How do we know this? Because this Proxy is accountable to you for the Team’s work — the Proxy is telling you ‘the story of what’s going on’, and this is the very definition of accountability.

Now, could you be the Team’s Product Owner? Yes. If you attended, and participated in, all the Daily Scrums, and didn’t need a Proxy to keep you ‘in the loop’, then you could consider yourself the Team’s Product Owner. That’s your decision; do you have the time and will to be the Team’s Product Owner, or not? How much time can you spend with the Team? Can you be ‘present’ enough so that you don’t need a Proxy, either formal or informal? That’s your call…

Here’s the trade-off: (spending the time and effort to actually be the Team’s Product Owner) versus (spending the time and effort to keep ‘synced-up’ with the Team’s Product Owner). The first choice is really hard to do, and the second choice is much easier but requires trust.

I usually recommend the second option. It’s cleaner. The separation is clear. The lines of accountability are well drawn. There is no overlap that can lead to misunderstandings and acrimony. In my opinion, this makes it more scrummish.

Here’s the diagram for this stretched-out Team with its two different Product Owners…

In this picture there are two Product Owners depicted. In practice, we need to change one (or both) of the names so we don’t get confused. The Team’s Product Owner is often called the Team Leader or Proxy, and the Product’s Product Owner is often called the Business Owner or Chief Product Owner. I tend to go with Business Owner and Team Leader, and say that the two of them, together, are doing Scrum’s Product Owner role… that we need two people because the totality of the Product Owner role was too big for one person — in this case because of the stretched-out nature of the Team. In other words,

Scrum’s Product Owner = Product’s Product Owner + Team’s Product Owner = Business Owner + Team Leader

Having a stretched-out team is not the only reason to do this dividing-up of the Product Owner role. It is not the only reason the Product Owner can be overloaded. The Product Owner role can be too much for a single person to do for a variety of reasons. Maybe the Business Owner needs to be with the Stakeholders ‘all the time’ even though they’re just down the hall. Maybe the Business Owner has another full-time job (maybe he or she is the Product Manager, for example). Maybe the Team Leader isn’t good at working with Stakeholders. There are lots of reasons.

Now, you may say that dividing the PO role ‘in half’ is not scrum, but you’d be wrong. Making trade-offs like these is required by Scrum as part of “inspecting and adapting” of the process. You adapt Scrum in this way because you have to — you are valuing Reality over Plans and Conversations over Artifacts, as it says to to in the Agile Manifesto. As the Scrum Guide says: “How [Product Ownership] is done may vary widely across organizations, Scrum Teams, and individuals.”