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 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.
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.
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.
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.