What does a Product Owner do in Scrum meetings?

The Product Owner is a business person making business decisions to maximize business results. “The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team.”*

Remember that a Product Owner is a full member of the Scrum Team. The Product Owner participates in every Scrum meeting, activity and event just like any other Scrum team member: collaborating, problem-solving, and being transparent. But that’s not where it ends. The Product Owner manages the Product Backlog and has additional responsibilities that affect exactly how they participate in each of the Scrum meetings.

The Product Owner in the Sprint Planning Meeting

The Product Owner actively participates in the entire Sprint Planning meeting. In many respects, the Product Owner leads the Sprint Planning meeting, while the Scrum Master facilitates the meeting.

The Product Owner must be prepared by ensuring the Product Backlog is “ready”, which, at a minimum, means that the Product Backlog is ordered and refined.
The Product Owner must arrive on time to the meeting. During the Sprint Planning meeting, the Product Owner must:

• remind the team of the Product Goal (or vision),
• explain how the ready Product Backlog Items are related to this goal,
• propose the expected value for the current Sprint to assist in creating the Sprint Goal, and
• answer questions about product backlog items to assist the Developer to select items and create a plan for doing the work.

The Product Owner may, just like any other Scrum Team member, participate in all the discussions about the Sprint Goal, the Sprint Backlog and the plan for how the work will get done.

There are also some things that the Product Owner must not do during the Sprint Planning meeting:

• completely avoid imposing solutions on the Developers, and
• completely avoid imposing the scope of work on the Developers (more on this below).

In other words, the Product Owner provides the business context for the work, but does not make decisions about the plan for the Sprint. It’s worth remembering that the Product Owner does retain some specific authority: their decisions about the Product Backlog must be respected!

Ultimately the Product Owner must let the team freely decide how many items are planned. This freedom allows the team to be truly motivated and committed to the work as well as being collectively accountable for getting that work done.

If the Product Owner forces a team to take on more work than it feels is within its capacity, then that dis-empowers the team, moves accountability for getting work done to the Product Owner, and completely dis-ables the team from getting to a high-performance state.

If the Product Owner is not letting the team freely decide how many items to take in a Sprint, then the Scrum Master needs to intervene. This situation is one of the main reasons that the Scrum Master and Product Owner should never be the same person: to protect the team from this sort of destructive pressure.

During Sprint Planning, the Product Owner influences the team’s plans for the Sprint in three ways:

• clarify the meaning of each Product Backlog Item to ensure that the team builds what the Product Owner actually wants,
• re-order the Product Backlog in such a way that the team is selecting items that lead to desirable business results, or
• stop sprinting altogether if the Product Owner determines that the team has ceased to be able to deliver more value in a Sprint than the cost of the Sprint.

The Product Owner in the Daily Scrum

The Daily Scrum is for the Developers… so the Product Owner participates as a Developer if they “are actively working on items in the Sprint Backlog.”* However, the Product Owner should be present at the Daily Scrum for two important reasons:

• to remind/clarify how the Sprint Goal relates to the overall Product Goal, and
• to take advantage of the transparency created in the Daily Scrum to anticipate business-related problems that need to be solved.

The Product Owner may or may not be actively involved with the rest of the Scrum Team during working hours. The Daily Scrum is a critical opportunity to “eliminate the need for other meetings”* so the Product Owner should take advantage of it.

Depending on the format of the Daily Scrum, the Product Owner may also respond to questions from the Developers. But the Product Owner should generally take a passive, observational role in the meeting. The Product Owner does not lead, facilitate or control the Daily Scrum in any way!

The Product Owner in the Sprint Review

The Sprint Review is a check point that helps the team to know the product’s current state, compare to its desired state, identify gaps, and take the needed steps to improve. This meeting is also where the Product Owner challenges the team to look at the product clearly. A demonstration of the Product Backlog Items completed in the Sprint is often a part of this meeting.

The Product Owner manages three important aspects of the Sprint Review and makes one important decision during the Sprint Review:

• selecting the audience,
• organizing the review of the Product Increment,
• updating the Product Backlog with feedback from the audience, and
• deciding if the Product Increment is “released” to customers / users.

The Product Owner determines the audience invited to participate in the Sprint Review. The audience should be as broad as possible while focusing on paying customers and users first, investors or sponsors secondarily, and other business stakeholders as logistics permits.

The whole Scrum Team also must be in attendance in order to have first-hand knowledge of the feedback their work is receiving.

The review of the Product Increment itself should be as hands-on, tangible and interactive as possible. The Product Owner may prepare scripts for participants to follow and may also allow participants to freely “play” with the product increment. In the language of technology, the Sprint Review is like “user acceptance testing”.

All the Scrum Team members gather at the end of the Sprint Review to collate the feedback and allow the Product Owner to process it enough to do a quick update to the Product Backlog.

This update can include adding new items, changing the order of items, removing future items, or even adding items to remove work previously done in the case that the feedback from stakeholders is negative!

If the Product Backlog never changes as a result of the Sprint Review or if the product itself never needs adjusting as a result of the Sprint Review, then it is likely that the Product Owner is not gaining the benefits of continuous improvement on the product.

The Product Owner has the sole authority on putting the work of the Scrum Team at the end of a Sprint into the hands of users.

There should be no other individuals who have the authority to do extra releases without the Product Owner’s approval, nor should there be anyone who can stop a release from going out if the Product Owner makes that decision. This is part of the Product Owner’s business decision-making authority.

If the Product Owner has this authority, it can create a high level of efficiency in addressing the needs of the business or the needs of the market.

If the Product Owner does not have this authority, then it undermines their authority over the ordering of the Product Backlog (since that ordering becomes meaningless) and it undermines the broader organization’s ability to hold the Product Owner accountable for results.

In larger organizations, there are often many bureaucratic and technical obstacles that need to be overcome before the Product Owner has this level of authority. This relates to the Scrum Team’s “Definition of Done”.

The Product Owner in the Sprint Retrospective

The Retrospective is the one Scrum event where the Product Owner participates exactly like any other Scrum Team member.
To be clear: just like any other team member, the Product Owner is a required participant in the Retrospective.

The Product Owner and Backlog Refinement

The Product Owner maintains the Product Backlog. This includes ordering (sequencing) in terms of value and effort, clarification, and identification of what acceptance criteria apply to each Product Backlog Item.

The refinement activity is unlike other activities in Scrum in that it is not time-boxed as a meeting. Instead the Scrum Guide gives us fairly specific guidance that refinement “is an ongoing process” and that the “Scrum Team decides how and when refinement is done.” The actual work of refinement involves the Developers working with the Product Owner to:

1. Add detail to Product Backlog items.
   Detail comes out mostly through splitting items that are too big to fit easily into a single Sprint. Splitting adds detail because the “new”, smaller items that make up the larger item each have unique information.
   Although adding detail is part of Backlog refinement, it is still important that Product Backlog items not become precise specifications and that that level of detail only comes out when the team starts work on the items during the Sprint.
2. Add estimates to Product Backlog items.
   There are two types of estimates that go on Product Backlog items: estimates of effort and estimates of business value. The Development Team is responsible for estimating effort. The Product Owner is responsible for estimating business value, and can include other stakeholders in that process.
   The estimates help the Product Owner and the Development Team make good business decisions about the work they are doing.
3. Add order to Product Backlog items.
   The Product Owner makes final decisions about the order and is accountable for that order leading to good business results. Both the detail and the estimates that come out of refinement are important factors to consider in ordering items.
   The Product Owner uses this information plus any market data, stakeholder feedback from the Sprint Review, and even new innovative or creative ideas all together to make decisions about the order of item.
   The Product Owner can change the order at any time.

Refinement is easiest when the Product Owner can also keep the whole Product Backlog in mind at the same time. This allows the Product Owner to see the big picture while dealing with tactical changes. There are two important techniques that help the Product Owner to do this:

• Keep the overall number of Product Backlog items small. A good rule of thumb is that thirty to forty is ideal, and after about eighty items it gets extremely difficult to keep it all in mind at the same time.
• Write each Product Backlog item on a single 3×5 note card (or virtual equivalent). This seems to be a reasonable limit to the amount of detail to write down before an item gets pulled into a Sprint Backlog.

Consider signing up for our Product Owner Boot Camp with CSPO to learn more about how to be an effective Product Owner.