Product Owner

A Product Owner is an essential part of a Scrum Team. The role is created to maximize the value of the work that the team delivers. It can be implemented in many ways, but how do you ensure that the role creates the most value in itself?

Usually, the Product Owner role is filled by either a business developer from the development organization or an employee from the business / customer. This person becomes an active part of everyday life in the Scrum team and is a driving force in the work with the Product Backlog: Ensures that there are continuous user stories ready for the next sprint, prioritizes user stories, obtains knowledge from the business, etc.

In many cases, the Product Owner participates in all Scrum events – Scrum, Planning, Review, Retrospective – and facilitates Refinement.

The advantage is that the team has a “goto guy” in connection with clarifying questions regarding tasks and prioritization which is constantly available.

One of the disadvantages of this constellation is that there is rarely a sufficient mandate with the role and energy is often used to create alignment around decisions outside the team. In addition, the Product Owner stays away from the customer / business for a longer period of time, which affects the ability to make decisions based on business needs without being colored by the team’s circumstances.

One can with great success try an alternative constellation and form of work. The purpose is to create mandate, ownership of product and short time from tank to product. To achieve this, 3 measures are introduced:

  • Direct ownership
  • Short refinement sessions
  • Introduced Story kickoff

Direct Ownership

Create direct and increased ownership by inserting a director from the business / customer as Product Owner. Make sure to coach the Product Owner in terms of expectations in relation to the importance of his input. His position in the organization means that he has a mandate to decide which direction he wants the product to take as well as prioritize the wishes to be developed.The team collaborate with him and a group of other stakeholders at Sprint Review. Here the team’s work and the team’s proposals are presented to wishes in the next Sprint.

Short refinement sessions

Many teams work with dedicated timeboxes to refine stories for upcoming sprints where there is talk of solution, design and architecture. It can be removed with advantage. Instead, work is done with quick allocation of story points and business value to create a sense of the value of the work and the size of the task / complexity.

Introduced story kickoff

To ensure that the team is aware of the solution, design and architecture, a “whole team approach” is used at the start of the task – a so-called “story kickoff”. Here the team gathers and agrees on how the work should proceed and “how little is enough” to create momentum on the product.

Why is it interesting?

If you can confirm one of the following hypotheses – then you should reconsider your Product Owner setup:

  • Product Owner needs a steering group to confirm priority
  • Product Owner does not have direct contact with customers / users of the product
  • Product Owner sits daily with the team, solves coordinating and administrative tasks
  • Product Owner performs backlog handling, writing user stories, etc.
  • It can be a radical shift to go from a Product Owner who is close to the Development Team to someone who is closer to the decisions. Try if necessary. to do a time-limited experiment and evaluate internally if you get more value delivered faster to the customer. If this is the case, then you also know what to work on in the future. You can advantageously revisit the above list periodically to see if the changes work.