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?

2 Answers 2


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.

  • And for larger projects? Are you're saying there should be one PO that understands all areas of the product, every detail, enough to be that one go-to person? Like in our case we're a small shop, 30 employees, but the product has many deep features (health care claims data loading, or insurance auditing and reporting sysyems, as examples) where there are separate biz SMEs that know each area deeply, far more than the one product owner does. Some areas take a good bit of collaboration on styling, layout, functional detail, etc. Is this when its ok for devs to work direct w stakeholders?
    – noahcoad
    Commented Sep 17, 2013 at 19:02
  • 1
    @noahcoad I say that there should be one PO who isolates the development team from all of the stakeholders (SMEs, users, clients, whoever else exists outside of the team) and understands the problem domain well enough to communicate with the team and stakeholders. If necessary, the team can interact with the appropriate stakeholders directly, but in order to make sure that the team doesn't receive conflicting information or pressure from outside forces, most communication between the team and stakeholders should flow through the PO.
    – Thomas Owens
    Commented Sep 17, 2013 at 22:37


"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.

  • I like your explanation of viewpoints, beneficiaries, and collaborators, but I want to mention that IMO the example you gave would have to be an epic (and a big one!) rather than a story, so it's a bit harder for me to wrap my head around the potential collaborators and roles for a story-sized piece of work.
    – Holly
    Commented Sep 16, 2013 at 21:04
  • @Holly Thanks for your comment. Epics are just really big stories that need to be decomposed further to be truly actionable. All the same rules and processes would apply. If you have a more illustrative user story that you'd like dissected, it might make a good separate question.
    – Todd A. Jacobs
    Commented Sep 16, 2013 at 21:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.