In SCRUM is it okay to have a separate 'product owner' per story?

Question

We have stories coming into the backlog from various business area owners, like product support, marketing, partner integration, etc. We have one Product Owner that manages overall backlog priority stack ranking. But we want our devs to be able to work directly with the person that is requesting the story for optimal collaboration.

We're calling that the 'Biz Contact' right now, but is there a more common use or term in SCRUM? Would they be considered the 'Product Owner' for that story? Or the 'stakeholder' of that story? Or is it expected in SCRUM that there is only ever one person, the single Product Owner, that the dev team works with for clarity and review of stories?

Answer 1

By definition, the Product Owner is a stakeholder representative and acts as Voice of the Customer. You should have one (and perhaps an alternate, should the primary be unavailable for an extended period of time) Product Owner for the product. Calling people the Product Owner for a story is overloading the term and may lead to confusion.

There's nothing prohibiting various Stakeholders from interfacing with the Scrum Team. Generally, the purpose of the Product Owner is to provide a buffer - Stakeholders can interact with one person instead of disrupting random members of the Scrum Team during the sprint and the Scrum Team can formulate questions and get them answered by Stakeholders through the Product Owner to ensure that they get timely answers, but without disrupting the daily work of these Stakeholders.

If you identify classes of Stakeholders (or, in a small enough environment, specific people), it may be valuable to tie the appropriate Stakeholder(s) or Stakeholder Class(es) to each User Story. However, I'd recommend caution with direct interaction between the Scrum Team and Stakeholders - there shouldn't be conflicting priorities, use cases, or expectations and exposing the team without going through a common interface may lead to problems.

In the end, it boils down to how sophisticated your team, Product Owner, and Scrum Master are at managing expectations, understanding limitations, and ensuring clear communication between all parties. There isn't anything in the process that precludes it, but adding communication channels does add some level of risk.

Answer 2

TL;DR

"One project, one Product Owner." Just like Highlander, there can be only one. However, stories are generally told from a specific viewpoint, and well-written stories often reference beneficiaries and collaborators.

Viewpoints, Beneficiaries, and Collaborators

When writing a user story, the generally accepted format involves starting with a viewpoint that defines the end-user or primary beneficiary of a feature. For example:

As a wealthy "one-percenter"
I want lower estate taxes
so that my children's inheritance is taxed more lightly than other income.

In this example, the critical viewpoint for the user story is that of the wealthy one-percenter. Sometimes the viewpoint character is someone the team will work with directly, but sometimes others act as proxies or spokesmen for the viewpoint.

The potential benefits of a story are not limited to the viewpoint character. In this example, the children also benefit from the feature even though the story isn't told from their point of view. They are beneficiaries of the user story.

As written, the user story also implies a number of other collaborators: attorneys, probate courts, tax advisors, and so on. These are people that may need to be consulted or actively engaged in order for the team to complete the story properly.

In my experience, collaborators (as opposed to the story's viewpoint or beneficiaries) are often implied by the story rather than explicitly called out. This may be a good thing that provides needed flexibility in story execution, or it may be a bad thing that makes the story's tasks less transparent to the project. Your mileage in this regard may vary widely.