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, along with the Development Team and the Scrum Master role.
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 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 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.
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.
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 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.
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.
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.
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.
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.
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 October 13, 2020, 4:23 pm
|0||Acceptance criteria||60 sec||SM, PO|
|1||Value for products||60 sec||SM, PO|
|2||The Product Owner represents the stakeholders||60 sec||SM, PO|
|3||Product Vision||60 sec||SM, PO|
|4||The Product Owner and the User Stories||60 sec||SM, PO|
|5||Release management||60 sec||SM, PO|
|6||The Product Owner role is part of the Scrum team||60 sec||SM, PO|
|7||The Product Owner and the prioritizing of the Product Backlog||60 sec||SM, PO|
|8||The Product Owner as the Scrum Product Manager||60 sec||SM, PO|
|9||Ending the product work||60 sec||SM, PO|
|10||User stories||60 sec||SM, PO|
|11||Understanding the Business||60 sec||SM, PO|
Comments from the BVOP™ community
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.