Scrum for Beginners 3-5-3 Part 2: Product Owner Role and 3 Pro-Patterns
Hello! This is Part 2 of a series on scrum using the 3-5-3 framework (3 roles, 5 events, and 3 outputs) where we use the Scrum Guide as a base for our learning.
In this article we will cover:
- What is the product owner role in scrum?
- What does a product owner do in scrum? What do they not do? 🌸
- 3 pro-patterns for a product owner in a scrum team 🌸
Click the emoji to jump to each section in the article.
What is the Product Owner role in scrum?
The product owner role (often shortened to "PO") exists only within the scrum framework. In practice, the PO shares some traits and accountabilities with a project manager and a product manager. We will go into detail about the differences in a different article. For now, let's refer to the Scrum Guide for what the PO is.
As a tip, if you want to know basic information about scrum, the Scrum Guide is a fantastic resource.
The Scrum Guide says:
The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team. How this is done may vary widely across organizations, Scrum Teams, and individuals.
From this, we understand that the PO "owns" the product, hence the name "Product Owner".
The Scrum Guide further clarifies the role further down:
The Product Owner is one person, not a committee. The Product Owner may represent the needs of many stakeholders in the Product Backlog. ...Those wanting to change the Product Backlog can do so by trying to convince the Product Owner.
In scrum, the PO role is taken by one person whose job it is to represent stakeholder needs and maximize the value of the product backlog.
In order to deepen our understanding, let's see what a PO does and doesn't do.
What does a Product Owner do? What do they not do?
The Scrum Guide talks about the accountabilities of each role. This is what it says for POs:
The Product Owner is also accountable for effective Product Backlog management, which includes:
Developing and explicitly communicating the Product Goal;
Creating and clearly communicating Product Backlog items;
Ordering Product Backlog items; and,
Ensuring that the Product Backlog is transparent, visible and understood.
Let's break this down a little bit farther.
Developing and explicitly communicating the Product Goal:
Why are we building this?
What problem/s are we trying to solve?
Who will it help?
How will we know?
How does sprint goal #246 connect to the overall product goal?
These are all questions that the PO must answer. They are not required to answer them alone but they are accountable for having the answers and communicating them effectively
Creating and clearly communicating Product Backlog items:
If a stakeholder wish, request, or need is going into the product backlog, its potential value must be understood. Additionally, the method of recording these items (JIRA, trello, poster on the wall etc) should be consistent and understood by those who will be designing and implementing it
Ordering Product Backlog items:
The product backlog is the responsibility of the PO. Only they can prioritize items in the product backlog. Items that are highest priority should be at the top ready to be pulled into the next sprint and in enough detail that the developers can work on them. Items that are lower priority can be less detailed to account for new information and changing priorities
Ensuring that the Product Backlog is transparent, visible and understood:
To put it simply: is it clear why we're building this instead of something else?
An easy way to check how transparent, visible, and understood a product backlog is is to ask the scrum team what the highest priority feature is and what the product vision is. If these are not understood, then the PO is accountable for insuring this is addressed
One final quote from the Scrum Guide gives us some insight into how the PO might achieve the above:
The Product Owner may do the above work or may delegate the responsibility to others. Regardless, the Product Owner remains accountable.
Now that we understand what the PO does let's look at a few things the PO does not do.
The PO does not:
- Say yes to whoever asks them for a new feature
they are not an order-taker and are instead accountable for having a clear product vision and gathering feedback on that vision - Instruct the development team on how to implement
they are accountable for seeking clarity from the development team and trusting the team to do the work - Manage the scrum team and the team's resources
they are accountable for seeking clarity on the team's situation and adjusting the scope and time as needed
3 pro-patterns for Product Owners in a scrum team
Here are 3 quick pro-patterns or good practices for POs in a scrum team:
1. Decisive decision-making
The PO role requires a lot of decision-making, including disappointing stakeholders by saying no. A PO who can make decisive decisions in service of the overall product vision can accomplish the role's goal of maximizing product value more than a PO who tries to fulfill everyone's wishes.
2. Keep the product backlog updated
An updated product backlog makes it easier for the scrum team and any domain experts to know where the priorities are. As a best practice, the product backlog should be updated when new information comes into the backlog. At the very least, having a properly updated product backlog is crucial for the scrum team going into sprint planning at the start of every sprint.
3. Practice telling the story of the product vision
The PO works with all stakeholders, some of which need to give their consent for budget and timeframe. Being able to communicate why your product is valuable is best done with a combination of numbers and story-telling. What is the journey of your product and those who will use it?
I hope this helps clear up some basic information about the PO role and gives you some inspiration for how you and your team can be more effective together.
