The Proxy Product Owner, a pattern in Scrum adoption: version 1

Below I try to describe a pattern that I've faced and have seen in other teams in the context of an Agile transition.
See the explanation section for more details on each of the sections in the pattern.
If you have faced similar situations let us know of your own story in the comments below.

Proxy Product Owner

Problem:

There are 2 or more Product Owners that give work to the Scrum team and the Scrum team has several systems to maintain. Each Product Owner owns only a subset of the systems the team works on and is only interested in the systems she owns.
The team is faced with unclear priorities, Product Owners who do not want to agree on the priority of each other items, and because each Product Owner has their own Product Backlog, the team has a hard time coordinating the work that they need to manage sometimes leading to the team creating their own Backlog that is hidden from the Product Owners, and where the real priorities are set without their knowledge (this is the Secret Team Backlog anti-pattern).

Context:

This pattern is applicable when the Product Owner community for one development team can not reach agreement without the intervention of a third person that will help them define the right priority for all the backlog items.
This pattern applies equally well if there is a decision within the organization that some products, and therefore the respective Product Owners, should receive a higher level of service.

Forces:

• Typically the team is paralized or hampered in their effort by the lack of clear priorities.
  
• In some cases the team ends up delivering features that are not in line with the company or customer needs
  
• The ScrumMaster will spend most of her day managing the Product Backlog and answering uncoordinated requests from all stakeholders
  
• Stakeholders include the Product Owners, but in some cases the Product Owners don't act as a proxy, but rather delegate their responsibility in the users/customers they represent. In this case the team and the ScrumMaster are faced with many conflicting signals about what the real priorities are.
  

Solution

The ScrumMaster takes charge of the Product Backlog, which in this case will become a Team Backlog, in that it includes items for all of the systems that the team manages, not just one product.
The first goal for the ScrumMaster is to get the Team Backlog in shape so that the team can start working from the Team Backlog without having to spend many hours getting the Backlog In Shape.
Once the team can consistently take items from the backlog without a need for large interactions with the Product Owners, then the ScrumMaster can start using the techniques described below for the proper prioritization of the Backlog by all stakeholders.
When several (2 or more) Product Owners are involved in the prioritization of the backlog it is important that all of them understand the need to serve all Product Owners and not just one, therefore the prioritization technique should reflect that fact.

Equal weight for all Product Owners

In this case all Product Owners have equal importance for the organization and therefore they should be assigned the same amount of decision power. That is done by giving each Product Owner 1000 points that they can distribute among all items in the Product Backlog. Each product owner knows that all others have the same amount of points to distribute, therefore they will be forced to "invest" more points into the stories/use cases/backlog items that they really want to get done in the next few iterations.
Each Product Owner may also invest points into other systems than their own, if that will help them get some feature in their own systems.

Different weight for each Product Owner

In this case one Product Owner is considered more important. He is given a larger percentage of the points available. The points given to each Product Owner should be similar to the company investment level decisions. For example, if a Product Owner's product is to receive 70% of the investment, the she should be assigned 70% of the points available for distribution among product backlog items.

Resulting context

• Once the ScrumMaster takes ownership of the Product Backlog the Product Owners will now focus on influencing her and get her to make decisions that are favorable to their needs. This should be avoided and the ScrumMaster should follow as much as possible the real results from the the prioritization done through the distribution of the points by the Product Owners
  
• In some situations some Product Owner will not do the prioritization before the Planning Meeting. In this case the ScrumMaster has a choice of letting the Product Owner assign a subset of her points during the meeting -- as not to delay the meeting too much; or then not allowing late prioritization, in which case the team will not work on the systems owned by that Product Owner.
  
• For this pattern to be implemented the ScrumMaster will have to spend a large part of each day managing the Team Backlog and communicating with the Product Owners. The team and ScrumMaster should be aware of this and decide to invest the ScrumMaster's time in that task.
  

Example

The ScrumMaster in one of our teams is frustrated with the Product Owners because they are never present, and hardly communicate with the team except to shout at them when something critical needs to be worked on "yesterday".
The ScrumMaster has taken the ownership of the different Product Backlogs and joined them into a Team Backlog, where items for all products are collected.
In this example, the team has not enforced a Force Ranked Priority on the backlog or Sprint Backlog, which then leads to a more difficult decision on the real priorities for each item that ends up in the Sprint Backlog. This leads to the stakeholders, who are not engaged, classifying every item as Critical or High priority. This situation then leads to the team in practice deciding which items are done first and which Product Owners are served first.

See Also (patterns and anti-patterns not defined yet):

• Team Backlog
• Backlog In Shape
• Planning Meeting
• Secret Team Backlog anti-pattern

Pattern format explanation

In "Name" I give a name to the pattern.
In "Problem" I describe the problem the team is facing in the form of a root cause and a set of symptoms that may be detected and lead to this problem.
In "Context" I explain where the pattern is applicable.
In "Forces" I try to describe the constraints or forces that the solution has to take into account.
In "Solution" I try to describe the instructions and practices to be used to solve the problem as described.
In "Example" I briefly explain the case of one team at work that has faced this problem and how they solved it.