Scrum Fundamentals: Product Owner-EN

This article is part of a series in which we will review the fundamentals of Scrum complemented with infographics that explain them. Access the other articles: Sprint, Planning, Daily, Review, Retrospective.

The Scrum Team is a “cohesive unit of professionals” where there are no hierarchies or sub-teams. However, there are essential functions that must be adequately covered, which in the Scrum Guide are called “accountabilities,” although they are also known as “roles”:

• Building the product with quality and excellence by the developers.
• Optimizing the workflow with the application of the Scrum framework, the Scrum Master’s mission.
• Maximizing the value of the delivered product is the Product Owner’s objective.

It is not surprising that the Product Owner‘s responsibility is one of the most talked about. Maximizing the value of the team’s activities involves identifying and characterizing very well the needs to be solved, ordering them appropriately over time according to various criteria (return on investment, dependencies, constraints…), and determining whether they have met the expectations or introducing the appropriate changes in each case…

The backlog, the main responsibility of the Product Owner

To be more specific, the Guide assigns the Product Owner the responsibility of managing the Product Backlog. This artifact contains the pending work to extend and improve the product. Furthermore, it should be the only source of work definition for the team: it should not address activities that are not captured there.

The most powerful tool of the Product Owner is the management of the backlog: it implies the ability to define the WHAT and the definition of the WHEN since the Product Backlog is an ordered list.

This does not mean that it is something that can only be done by the PO’s responsibility. Adding elements to the backlog, refining and ordering them is an activity where other people can participate. But the final responsibility will always be on the Product Owner.

What does “managing the backlog” mean? According to the Scrum Guide, it means:

• Developing and explicitly communicating the Product Objective. Recall that there is a “Sprint Goal” that is defined during the Planning event and that expresses the value that will be brought to the product during the Sprint. This Product Goal is the long-term goal of the team, describes the future state of the product and serves as a guide for planning, pointing to the destination.
• Create and clearly communicate outstanding work items. A PO is expected to be able to convey the product vision, goals, context… This is why it is often said that the PO carries “the voice of the customer”.
• Request that product items expressed as PBIs (Product Backlog Items) are carried out.
• Ensure that the Product Backlog is transparent, visible and understandable.

The responsibilities of a Product Owner

Through the management of the Product Backlog, a Product Owner is in charge of defining and modulating the work of the rest of the team, establishing the What and the When.

Frequent contact with the stakeholders

For this reason, they are in frequent contact with the different stakeholders of the product, people and organizations that can influence and have an interest in the product. As this interest and influence can vary greatly, it is the Product Owner’s responsibility to understand the needs of the different stakeholders and know how to give them the most appropriate relevance and priority at all times.

Managing the Product Backlog

As PO, he must translate those needs, which are the raw material of the whole process, into something more refined and “workable” so that it can be translated into Backlog items (PBIs) and can be transformed by the Developers into something tangible: the product increment.

Availability to the team

When refining needs into work items, a Product Owner can count on the support of other people, even from outside the team. Translating raw needs, problems and demands… into refined work units or PBIs requires the PO to be able to “speak two languages”: that of his stakeholders and that of his team. The more knowledge he has of both the better, but he does not need to be an expert from a technical point of view (for that there are already the Developers).

In addition, as a Product Owner, you must attend to the doubts, questions and needs of the rest of the team. A conversation is much more efficient and effective than avoiding it with complete and extensive definitions.

A conversation gives rise to other visions on how to address the needs of stakeholders, encouraging the active participation of the team and increasing their commitment. No matter how hard we try, language tends to be ambiguous and incomplete, and lengthy, over-documented requirements create false certainty and security.

A simpler vision that encourages dialogue between the Product Owner and Developers is better, which explains the popularity of techniques such as User Stories (US) to express PBIs.

For all these reasons, the Product Owner’s work tends to be full-time: frequent contact with stakeholders, availability to the team and work with the Product Backlog are tasks that make it difficult to combine them with other activities.

In addition, the responsibilities of the Product Owner are of a single person so there is only one criteria when defining and prioritizing the work. It must be a person who is part of the team, since having Product Owners who are distant or outside the team, or multiple Product Owners are a source of dysfunctions and problems.

Product Owner and events

As part of the Scrum Team, whoever has the responsibility of Product Owner participates in the different events of the Sprint:

Planning

During planning, he has an active and prominent participation: he raises the first approximation of the objective, provides the point of view of the Business on behalf of the stakeholders, has the power to prioritize and is the one with whom the team negotiates the scope and plan of the Sprint. It is at this moment when the natural tension between the PO’s desire to deliver more and the reality of the team’s capacity, its context, the unknowns, the history, or the debt accumulated in the work tends to emerge.

Review

In the review he has a special role as he must give feedback on the work done together with the stakeholders who may have attended. It is not the only occasion on which to give this feedback since, as PO, he is at the disposal of the team, which can at any time show the state of the product and make decisions about it.

Retrospective

During the retrospective, he participates as part of the Scrum team and is expected to contribute to the team’s continuous improvement process.

Daily Scrum

It is often debated whether or not to attend the daily meetings. As defined in the Scrum Guide, this meeting is by and for the developers, and the PO attends if he combines his main activity with participating in development. If not, he should attend by invitation only: it is not an event for the team, it is only for the Developers on the team.

Download infographic