Who is The Product Owner

Introduction The Product Owner is one of the members of the Scrum Team and have three main responsibilities:

  • Act as liaison for the Development Team to business and the end-users, when the Development Team need clarification of the User Stories or feedback on alternative ways to implement an User Story.
  • To maximise the value for the business and end-users of the deliverables from the Development Team by making sure User Stories are  unambiguous, complete, correct, consistent, and verifiable.
  • Being custodian of the Release Backlog.

The Product Owner is one person – not a committee – and the entire organisation must respected the decision she or he take.
Which responsibilities do the Product Owner have? The Product Owner have these responsibilities:

Responsibility Description of task
Establish the Release Backlog The release backlog is established based on the Product Backlog, which contains the User Stories or Epics reflecting the requirements from the organisation to the product.
When new development are planned – either completely new or increment to existing product, the Product Owner select from the “top” of the Product Backlog the User Stories or Epics that shall be implemented in the new development.
The Release Backlog can either be marked in the existing archive for the actual release or be in a separate archive to which the User Stories or Epics are transferred.
Safe guarding the Release Backlog During the release the Product Owner safe guard the User Stories or Epics not yet selected for implementation in a Sprint from any unauthorised changes.
Anyone who want to change the content of the Release Backlog, either by adding, changing or deleting User Stories or Epics, need to negotiate and obtain the acceptance from the Product Owner.
The Product Owner is the only one who can make changes to the Release Backlog.
Refining the Release Backlog Together with members from the Development Team the Product Owner refine the Release Backlog. The purpose of this refinement is to ensure that the items in the Release Backlog is fit for implementation in a Sprint. The refinement is done gradually during the release, the highest priority User Stories or Epics first and only so many as needed to make sure there are enough to select for the next one or two Sprints.
The refinement is mainly focused on two things:

  • Breaking Epics down into a number of User Stories that more detailed describe the needs reflected in the Epic and which have a size that fit for implementation in a Sprint.
  • Refine the wording in the User Stories to make them adhere to the accept criteria expressed in INVEST.
Support to the Development Team During the Sprint the Product Owner support the Development Team in three ways:

  • Interpretation of the User Stories in order to ensure the solution that provide the best value for the business. This can be done either directly by the Product Owner or by guiding the Development Team to the relevant Subject Matter Experts.
  • Deciding if any change should be made to the Sprint Backlog , but no changes can be made without the Development Teams acceptance that they would not endanger the Sprint Goal.
  • Presenting the result from the work in the Sprint at the Sprint Review for the invited stakeholders>.

Hints and References The Definitive Guide to Scrum: The Rules of the Game; November 2017; https://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-US.pdf

Essential Scrum; A Practical Guide to the Most Popular Agile Process; Kenneth S. Rubin; Addison-Wesley; ISBN-13: 978-0-13-704329-3; ISBN-10: 0-13-704329-3.

The Backlog can be either a tool or very simple a excel sheet which is kept under change control with the Product Owner being the only one with write access to the file.