Skip to main content
Special announcement All BVOP™ certification programs are offered with a significant cost reduction. BVOP's mission is to support professionals worldwide. Online Certification Exam
for $ 45
Register now
Get Certified

The Product Owner role

The following article is a sample from the full BVOP™ Ultimate Guide and is part of the preparation for the BVOP™'s modern Agile Project Management Certification Program.

There is no hierarchy in Scrum. However, the responsibilities must be clearly 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 stakeholder 

The Product Owner role is the "stakeholder voice" to the team and is responsible for creating value that comes from the work of the Development team.

In any team and project, people can work hard and work on a schedule. But in theory, as much as teams work, they are always likely to put effort into parts of the product that may not be as important. 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. They are not only User Stories but also defects (bugs), research tasks or technical improvements, ideas, etc. Their most popular 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 activities. When we talk about User Stories, we put the word "tasks" in quotes because these may not be real assigned tasks of the team. Each User Story can be broken down into separate small tasks that the team works on. User Story is understood to be a whole great idea that can be developed by different people, and everyone can do their part. Breaking down a User Story into small tasks can be done to facilitate the team, with each team member having a specific task. Keeping track of the work done and controlling the process can also be easier.

The Product Owner role works with stakeholders and represents their interest. He or she is looking for ways to satisfy their interests and 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 who the actual users of the product are, what their needs or expectations are. How the product will be distributed, sales methods, and other market factors are also described. What are the main factors that will determine 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 a Product Vision is Product Manager activity. But since Scrum does not include a Product Manager role, the Product Owner role is the closest understanding of the 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.

Stakeholder (owners, investors, partners, agents) value can be measured at some profit or benefit - financial gain, economic or marketing advantage.

The Product Owner and the prioritizing of the Product Backlog

Another important activity of Product Owner, besides prioritizing work by arranging the entire contents of the Product Backlog, is to ensure that there are fully prepared Product Backlog Items for the current Sprint and Increment. This means that the User Stories that the team is expected to work on during the Sprint should be completely clear, detailed, and understandable by everyone.

Understanding the Business

The Product Owner role as a stakeholder representative (and their needs) must fully understand the expectations of the business parties. The Product Owner 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 Outer 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" stakeholder desires and records them in the form of User Stories using a country-wide language.

In the process, however, Product Owner and Scrum Master roles communicate to understand Product Owner whether the Development team understands 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 Story describes a user who needs functionality, context, and 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 should be logical independently of the others. User Stories should not overlap. They should be "broken down" in a way that allows the team to predict the development time needed easily.

Another essential feature of User Story is that it is recommended that it can be developed in Sprint. If a sprint is one week, a user story should take a maximum of one week to be created, tested, and accepted by stakeholders. User Story should allow easy testing, validation, and acceptance.

The logic and work behind a User Story should be simple, clear, and concise enough for teams to test it easily and for stakeholders to review, understand, and accept it.

Acceptance criteria

A User Story is recommended to include an Acceptance criteria section, which is an important part of any user story. 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.

User Story cannot be "accepted" in part for any reason. All conditions must be met. If some team members say that almost all work has been done and "only small things remain", it is advisable to pay attention to such opinions.

Product Owner, tempted by the idea of ​​small things remaining, can also agree to such an "agreement" for remaining small work on tasks. Incomplete parts or tests can lead to product issues or harm businesses or processes.

Ending the product work

Although there may be a lot of planned work, business stakeholders can at any time state that the work on the product is being terminated. In Waterfall project management understandings, such a situation is viewed as negative and often leads to stress.

A very likely reason for this suspension of work may be spending more than planned or some other drastic change in business.

If the Scrum team is shut down, this should not be considered a negative event. It is highly probable that work will be stopped since 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. Many Product Backlog items can refer to functionality that is not very 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 Product Backlog on an ongoing and regular basis, 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 spin, the team first works on User Stories, which are listed above in the Product Backlog. The User Stories prioritized at the top of the Product Backlog logically 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 finished work. Project Managers, Product Managers, Product Owners different roles from different methodologies, often use this term.

A release may mean some definite finished form of part of a product or some specific version of it, modified, improved, or in a more advanced form than previous versions.

A release can also be used as a phase or 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 technical team members are discussing what will be achieved for the next release. The Scrum Master role can also be involved in planning and discussions, as it is a role that protects teams and takes care of processes and best practices at the same time. Discussions and arrangements should take into account both the wishes of stakeholders and 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.

What is a Scrum Product Owner? Definition and Responsibilities
Comments of our guests
  1. Gregory J, Cooper
    Hi BVOP. I would like to ask some questions that concern me directly. To what extent the Product Owner role should be proficient in popular product management practices such as user analysis, competition analysis, marketing, design and prototyping, and more. Should the Product Owner role play a part in defining the product roadmap? Thanks in advance. Greetings from Greg
  2. Anna Haruto
    @Gregory As far as I'm aware, the Product Owner is a kind of product role, but it's not a classic product manager. We cannot compare the two concepts, but in real life, the more skills this role holds, the more productive and meaningful his work will be. Often, stakeholders and senior management roles can work with the Product Owner and do the activities you mention in your question.

Web site
Your Comment

The BVOP Certificates

Certified Chief Executive

The BVOP Chief Executive is the core driver of the Business Value-Oriented Principles and the most advanced figure and leads the interest of the organization.

Get Certificate $1290   $720

Certified Program Director

The BVOP Program Director manages the entire Program Management Office and possess exceptional expertise and applies strategies.

Get Certificate $720   $490

Certified Agile Director

The BVOP Director is the most advanced and important role inside Agile products and services-based organizations.

Get Certificate $440   $220

Certified Project Manager

The BVOP Project Manager is an advanced and competent business, product, and technical role and a key factor for the success of the projects.

Get Certificate $280   $130

Certified Product Manager

With the advancing design, development, technical, and business knowledge, the BVOP Product Manager is a master role and decision-maker for the products.

Get Certificate $280   $130

Certified Product Owner

Responsible and skilled BVOP Product Owners balance both business and technical needs using Agile approaches and provide business value for products.

Get Certificate $180   $90

Certified Scrum Master

The BVOP Scrum Master role combines skills, Agile thinking, and project management practices to enchant processes, teams, and stakeholders.

Get Certificate $140   $70

Certified Human Resources Manager

People are the greatest assets of any organization. Balancing the people and organization needs

Get Certificate $140   $70