The following article is part of the self-preparation for the modern BVOP® Scrum Master Certification program.
What is a Scrum Product Owner? This chapter describes the definition of the role and explains all the responsibilities of the traditional Product Owner.
- The Product Owner role is part of the Scrum team
- The Product Owner represents the stakeholders
- The Product Owner and the User Stories
- Product Vision
- The Product Owner as the Scrum Product Manager
- Value for products
- The Product Owner and the prioritizing of the Product Backlog
- Understanding the Business
- User stories
- Release management
There is no hierarchy in Scrum. However, the responsibilities must be known and respected.
The Product Owner role is part of the Scrum team
The Product Owner role is part of the Scrum team, along with the Development Team and the Scrum Master role.
The Product Owner represents the stakeholders
People can have a work schedule and work hard on every project but there is always the likelihood that they will put effort into parts that are not that important. The Product Owner role is the "stakeholders' voice" and is responsible for giving value to the work that comes from the Development team. Value, in this case, means producing an effort (work) on tasks that are of the utmost importance to the product.
The Product Owner and the User Stories
The Product Owner role creates user-oriented "tasks" (items). Items have a broad meaning and include not only User Stories but also defects (bugs), research tasks or technical improvements, ideas, etc. The most popular item format is called User Stories. These are the "tasks" that the entire team works on to create the product.
The Product Owner also prioritizes the entire User Stories list (the Product Backlog) so that the team can focus on the most valuable ones. User stories can be broken down to separate small tasks, which facilitates the team and makes tracking and control a bit easier. User Story can be defined as a whole idea that is developed by one or a number of team members who each do their part (task or tasks).
The Product Owner role works with stakeholders and represents their interest. He or she is looking for ways to satisfy their product requirements.
Sometimes, before the actual work starts, the Product Owner and the stakeholders create the so-called Product Vision.
Product Vision
Product Vision is a collection of information divided into groups. Data is collected on the actual users of the product, their needs or expectations, ways of distribution, sales methods, and other market factors. The factors determining the price can also often be a theme in the Product Vision.
When all this information is gathered, the Product Vision serves as a basis for creating ideas, concepts, prototypes for the project, as well as its actual production.
In classic Product Management, working on the Product Vision is Product Manager activity. But since Scrum does not include a Product Manager role, the Product Owner role is the closest to Product Manager.
The Product Owner as the Scrum Product Manager
Although the Scrum Guide does not provide any details about actual product knowledge and practices, BVOP suggests that the Product Owner should have product knowledge. This role should also have knowledge of product users, the market and its features, competition, and modern trends in the industry.
The primary responsibilities of the Product Owner role can be defined as:
- Keeping an idea and vision of how the product will develop.
- Continuous cooperation and communication with stakeholders.
- Creating and maintaining a Product Backlog - writing User Stories.
- Prioritize Product Backlog.
- Release Management - Define phases and release dates for new product releases.
- Track work progress, time, and budget.
Value for products
The Product Owner must "create" a product that delivers real value to its users, customers, and stakeholders.
But what does this mean?
Consumer value can be any convenience, utility, or social or professional benefit. If the product is new storage software, then its users should expect more accurate storage details, more comfortable or faster use.
Value for stakeholders (owners, investors, partners, agents) can be measured in profit or benefit - financial gain, economic or marketing advantage.
The Product Owner and the prioritizing of the Product Backlog
The Product Owner needs to prioritize the work according to the Product Backlog and ensure that the items in it are fully prepared for the current Sprint and Increment. This means that all User Stories that the team is expected to work on during the Sprint should be clear, detailed, and understandable by everyone.
Understanding the Business
The Product Owner role as stakeholders' representative (and their needs) must fully understand the expectations of the business parties. It is a liaison between business stakeholders and the Development team. The Product Owner communicates with various business representatives, collects information on upcoming sprints, shares team progress.
When a team member encounters ambiguity in a task, the Product Owner should be there to assist and share information, details, or an alternative product solution.
The Product Owner does not relate to the way the teams do their work, does not share technical suggestions or specific technical methods of implementation.
User stories
The Product Owner "translates" stakeholders' desires and records them in the form of User Stories using an understandable language.
In the process, the Product Owner and the Scrum Master roles communicate with the Development team to ensure that they understand the user stories.
User Story is an informal and brief description of any consumer need. Usually, a User Story is a written form that represents the perspective of the potential consumer of the product regarding its functionality. User Stories are based on users who need functionality and have goals.
For clarity, let's describe what a User Story might look like. The user story follows a standard and is created using the following format:
As a (role), I need (capability), so that (receive the benefit).
(role) - The role is "who" needs something.
(capability) - the exact need
(receive the benefit) - a positive result for one who requires something (the user).
Each User Story is advised to be logically independent regardless of the others. It’s not recommended for user stories to overlap. They can be "broken down" in a way that allows the team to predict the development time easily.
It is recommended that a User Story is created in such a way that it can be completed within a Sprint. If a duration of a Sprint is one week, this means that the User Story should not take more than that to be created, tested, and accepted (approved) by stakeholders. It should allow easy testing, validation, and acceptance.
Acceptance criteria
A User Story is recommended to include an Acceptance criteria section, as it is an important part. These "acceptance criteria" contain the "conditions" that the work of the Development Team must meet.
Acceptance criteria are added to each User Story to guide testing conditions.
A User Story cannot be accepted partly for any reason. All conditions must be met. It is advisable to be cautious when stating that the work is almost done or only small things (tasks) remain.
The Product Owner can be tempted to agree to these incomplete parts or tests, which can lead to product issues and harm the business or processes.
Ending the product work
The business stakeholders can terminate any developing product at any time and completely cease the work on it. In Waterfall project management understanding, such a situation is considered negative and often leads to high levels of stress.
A very likely reason for this suspension of work may be spending more resources than planned or some other drastic change in the business.
If the Scrum team is shut down, this should not be considered a negative event. It is highly probable that the work is ceased because the business is satisfied with the product created so far.
Let's include the topic of prioritization now.
Let's say we have 500 Product Backlog Items. Most of them are User Stories. A large number of them describe important functionalities and product ideas. Others contain ideas for developing functionalities that can be seen as secondary. And the third may be trivial ideas that are recorded in the Product Backlog at the explicit request of the stakeholders.
With a list of 500 development proposals, many are unlikely to have high product value. The functionality of many of those items may not be valuable to the product.
If 300 User Stories have already been developed, starting with the most important ideas, the stakeholders may already be satisfied and do not see the need to continue working on insignificant ideas.
Therefore, the primary responsibility of the Product Owner role is to prioritize the content of the Product Backlog regularly, based on a number of factors.
Of all the prioritized Product Backlog Items, the Development Team decides how many tasks it can develop during a Sprint. Logically, during the Sprint, the team works on the User Stories, which are listed at the top of the Product Backlog. These stories become part of the Sprint Backlog list.
Release management
To easily discuss the issue of Release Management, let's clarify what Release is.
The release is understood as releasing or providing completed work. Project Managers, Product Managers, Product Owners, and other roles from different methodologies, often use this term.
A release may mean a finished part of a product or a specific version that has been modified or made more advanced than previous ones.
A release can also be used as a phase or a period. For example:
"In Release 2, we are completing user registration. In Release 3, we need to fix any registration defects."
Stakeholders, the Product Owner, and possibly the technical team members discuss what will be achieved for the next release. The Scrum Master role can also be involved in planning and discussions. It is a role that protects teams, and takes care of processes and the best practices at the same time. Discussions and arrangements should take into account both the wishes of stakeholders, their needs and expectations, as well as the capabilities and capacity of the Development Team.
Strategy and goals are created. Steps for releasing the release can be described. The specific tasks to be worked on are also often indicated in the planning of a release.
The following issues related to chapter "The Product Owner role" are included in the certification exam. The sequence of questions is presented in the table.
The data is current as of December 11, 2024, 7:35 am
| ID | Issue | Time | Category |
|---|---|---|---|
| 0 | Value for products | 60 sec | SM, PO |
| 1 | Ending the product work | 60 sec | SM, PO |
| 2 | Acceptance criteria | 60 sec | SM, PO |
| 3 | User stories | 60 sec | SM, PO |
| 4 | The Product Owner role is part of the Scrum team | 60 sec | SM, PO |
| 5 | The Product Owner as the Scrum Product Manager | 60 sec | SM, PO |
| 6 | The Product Owner represents the stakeholders | 60 sec | SM, PO |
| 7 | Release management | 60 sec | SM, PO |
| 8 | The Product Owner and the prioritizing of the Product Backlog | 60 sec | SM, PO |
| 9 | Understanding the Business | 60 sec | SM, PO |
| 10 | Product Vision | 60 sec | SM, PO |
| 11 | The Product Owner and the User Stories | 60 sec | SM, PO |
Comments from the BVOP™ community on "The Product Owner role"
Further reading
Managing the Product Backlog
Managing the product backlog is not exactly a responsibility for this role in the Scrum framework but refers to a more complex activity.
The Product Owner works closely with both stakeholders and the Development team and during the planning meeting is again responsible for maximizing the value of the developed outcome.
Detailed approaches and techniques for both product backlog prioritization and management are described and presented in the BVOP Ultimate Guide.
Summary
Scrum has no hierarchy, but responsibilities must be respected. The Product Owner is part of the Scrum team and represents stakeholders. They prioritize tasks that add value to the product.
The Product Owner creates tasks for the team, including User Stories, defects, research tasks, and ideas. User Stories are the most popular format and the Product Owner prioritizes them. User Stories can be broken down into smaller tasks. The Product Owner represents stakeholder interests and aims to meet their requirements. They may create a Product Vision with stakeholders before work begins.
Basis for creating ideas
Product Vision is a collection of data on users, their needs, distribution, sales methods, and market factors. It serves as a basis for creating ideas, concepts, prototypes, and production. In Scrum, the Product Owner role is closest to the traditional Product Manager role.
The Product Owner in Scrum should have knowledge of the product, users, market, competition, and industry trends. Their main responsibilities include keeping a vision of the product, communicating with stakeholders, creating and prioritizing the Product Backlog, managing releases, and tracking progress, time, and budget.
The Product Owner must create a valuable product for users, customers, and stakeholders. Consumer value can be convenience, utility, or professional benefit. Stakeholder value can be measured in profit or benefit. The Product Owner must prioritize the Product Backlog and ensure that all User Stories are clear and detailed for the team to work on during the Sprint.
Liaison between business stakeholders and the Development team
The Product Owner acts as a liaison between business stakeholders and the Development team. They must understand the expectations of the business parties and communicate with various representatives. The Product Owner also assists team members with ambiguity in tasks but does not provide technical suggestions or methods.
User stories are brief descriptions of consumer needs that are recorded by the Product Owner in an understandable language. The Development team communicates with the Product Owner and the Scrum Master to ensure they understand the user stories. Each user story follows a standard format: "As a (role), I need (capability), so that (receive the benefit)." User stories should be logically independent and not overlap. They should be broken down for easy development time prediction and completed within a Sprint's duration. This allows for easy testing, validation, and acceptance by stakeholders.
Guide testing conditions
Include "Acceptance criteria" section in User Story to guide testing conditions. All conditions must be met for the Development Team's work to be accepted. Avoid stating that the work is almost done or only small tasks remain, as incomplete parts or tests can harm business or processes.
Product work can be terminated by business stakeholders at any time due to reasons like overspending or drastic changes. In Waterfall project management, this is seen as negative and stressful. However, in Scrum, it may indicate satisfaction with the product. Prioritization is important in managing a large Product Backlog. The Product Owner's role is to regularly prioritize based on various factors. The Development Team works on the top-priority User Stories during the Sprint.
Providing the completed work
Release Management is the process of providing completed work. It involves different roles such as Project Managers, Product Managers, and Product Owners. A release can refer to a finished part of a product or a specific version that has been modified. Stakeholders, Product Owners, and technical team members discuss what will be achieved for the next release. The Scrum Master role can also be involved in planning and discussions. Strategy and goals are created, and steps for releasing the release are described. Specific tasks are also indicated in the planning of a release.
- Previous article The Elements of Scrum
