5 Responsibilities of the Product Owner

Wish your Product Owner would do their job? Are you tired of pickup up their slack? Having clear responsibilities is a prerequisite to building accountable teams. Before you fly off the handle, take a moment to make sure everyone has the same expectations.

Key Responsibilities of a Product Owner

The Product Owner has five key responsibilities:

1. Envisioning the Product
2. Working with the Product Backlog
3. Planning the Release
4. Collaborating in the Sprint Meetings
5. Managing the Stakeholders

Envisioning the Product

The Product Owner will need to digest feedback from all stakeholders and construct a vision for the product. The product vision will be used as a rallying point for the team and helps set the stage for future Product and Sprint goals.

This vision should be short yet broad and engaging. A brief vision statement allows for easy recall and encourages sharing (think elevator pitch). A general proclamation of direction will enable us to maintain the ability to pivot as we learn more throughout the development process.

“Simplicity is the ultimate sophistication.”

-Leonardo da Vinci

Focusing the vision on a Minimal Marketable Product will help us take baby steps that permit validation of our assumptions along the way. The MMP approach helps ensure that we’re solving the stakeholder need, reducing risk, and quickly earning income.

A few of the more common techniques for developing a product vision are personas, the vision box, prototyping, and the Kano Model.

Once drafted, seek customer feedback to validate that the draft aligns with the customer vision. If they see any issues, it’s better to find out now than after we’ve started development in that direction.

Working with the Product Backlog

The Scrum Guide gives us four items for which the Product Owner is accountable. Of those, three revolve around the Product Backlog.

• “Creating and clearly communicating Product Backlog items;
• Ordering Product Backlog items; and,
• Ensuring that the Product Backlog is transparent, visible and understood.”

-Scrum Guide

A healthy Product Backlog will conform to the qualities defined by the DEEP mnemonic. This acronym stands for Detailed Appropriately, Estimated, Emergent, and Prioritized.

Detailed as a quality makes sense. The more details, the better, right?

The addition of the word appropriately is very applicable here and shouldn’t be overlooked. The phrase implies that it’s possible to be detailed inappropriately. We can avoid this paradox in two principal ways.

First, don’t over document your Product Backlog Items. A user story’s purpose is to serve as a placeholder to have a conversation. Strive to include just as much detail as necessary to jog the memory.

The second way to avoid inappropriate details is to limit the number of PBIs created. We only need just enough to cover Sprint Planning, and we’ve inappropriately detailed if we make enough PBIs to cover the next six years.

Estimated refers to the need to have a size assigned to each Product Backlog ltem. Estimates are used to ensure shared understanding and facilitate planning.

Emergent refers to the natural process of progressive elaboration that occurs when doing knowledge work. Things change as we learn more about the product we’re building. This is precisely why you don’t want to detail your PBIs too far in advance; everything is subject to change.

Prioritized refers to ordering stories in the Product Backlog. We place the items that will provide the most customer value toward the top of the backlog. In theory, the Development Team will work on requests from the top first, so those items will be more detailed and should be the ones we’re planning to release in the near horizon.

When possible, the Scrum Team performs the discovery and creation of product backlog items collaboratively, ensuring a shared understanding. Inputs to this process are customer feedback and the product vision.

FOMO (fear of missing out) might lead you to add every little passing idea to the Product Backlog. I encourage you to challenge this approach. Again, we should be focusing on the minimum marketable feature. Once we’ve got a potentially shippable increment out, we can evaluate our next highest priorities. If a requirement is a genuine need, stakeholders will not forget it. Alternatively, adding every passing thought to the backlog will make it unmanageable.

Backlog refinement (sometimes called grooming) is the process of keeping our PBIs culled, prioritized, and appropriately detailed. If we want to stick with the shirt metaphor above, this is giving away the shirts we aren’t going to wear, mending the ones with holes, and folding and stacking the remainder in priority order.

Planning the Release

At the end of each Sprint, the Development Team will deliver a potentially shippable increment. That odd wording: potentially shippable indicates that it’s not guaranteed to ship.

Consider an application that requires the ability to print. There is little value in printing without the ability to preview what we’re sending to the printer. What do we do if we need both capabilities, but the Scrum Team can only deliver one in the Sprint? We don’t release until the second Sprint when both capabilities are done. The team has provided a potentially shippable increment for each Sprint; we just chose not to ship it.

The ship or no ship decision is the responsibility of the Product Owner. Other activities that go along with this are managing scope, schedule, and budget.

Collaborating in the Sprint Meetings

The Product Owner is not required (and may not be able) to attend all Scrum events. However, their attendance is strongly encouraged. Questions regarding scope and priority arise often, and the Product Owner needs to be available to respond to these inquiries.

Product Backlog Items aren’t intended to be mini contracts with all the details present for the Development Team to execute with 100% certainty. The expectation is that the team is constantly communicating and resolving discrepancies to reach a shared understanding, which requires the Product Owner to be frequently available.

The Sprint Planning meeting is the event in which the Product Owner will be most involved. A lot of pre-work needs to happen before the meeting to ensure the Product Balog is up to snuff. The most significant portion of the event will be the Product Owner explaining the functionality to the Scrum Team and ensuring that issues are sized and understood appropriately. Without a solid understanding of the customer’s needs, it’s impossible to provide estimates or be confident in accomplishing the Sprint Goal.

Managing the Stakeholders

The Product Owner is the direct line between the Scrum Team and customer requirements.

Customer requirements filter through the Product owner and are translated into Product Backlog items when they align with the product’s vision and are necessary to accomplish the Product Goal. Picking and choosing which requests make their way to the backlog is similar to deciding which colors make their way to a canvas.

Key stakeholders will not be happy to hear that their features will not be part of the final product. A professional Scrum Product Owner will have the courage and excellent communication skills, enabling them to convey the logic behind their decisions.

The organization must trust the person in this role to make these decisions or undermine the whole process.

Works Consulted

• Scrum Guide
• Agile Product Management with Scrum: Creating Products that Customers Love
• Scrum Guide 2020 Update - Introducing the Product Goal
• Product Goals in Scrum
• The Minimal Marketable Product
• Making the Product Backlog Deep

TLDR

If your Product Owner seems over-taxed, there is probably a good reason. The activities required to support each of these responsibilities are considerable. Instead of being frustrated with your colleague’s ability to handle the workload, look for ways to improve processes to be more efficient and enable the ability to focus on the things that matter most.