The Role of the Product Owner in Scrum

The concept of a Product Owner in Scrum evolved from the Chief Engineer role pioneered by Toyota in the car manufacturing industry. By crossing from manufacturing into software delivery, it is now a formative component of Scrum and one of three defined roles in the framework. Considering the importance of this role, a frequently asked question in Agile 101 sessions is what does a Product Owner do and what challenges exist when establishing the role? This article sets out to answer these questions. We can begin by listing some of the key responsibilities for a Product Owner:

• Set the product vision, and with support from the entire scrum team, drive the success of the product
• Lead the backlog ‘grooming’ (i.e. prioritization) meeting and set the product roadmap and sprint priorities
• Collaborate with the scrum team to sign off requirements’ acceptance criteria and when requirements can be considered done (i.e. built, tested, demoed and ready for release)
• Participate in sprint meetings acting as a single decision-making authority
• Cultivate relationships with product stakeholders and protect the scrum team from ad hoc requirement requests

This list isn’t exhaustive but does highlight how Product Owner roles demand a diverse skill set to engage with both business and technology teams. Below are some common skills we should expect to see Product Owners demonstrate in their roles:

• Stakeholder management: the ability to manage multiple stakeholders across the business to ensure the product vision is defined and supported
• Product knowledge: an ability to understand – ideally at an intricate level – the design, function and build of the product in order to set a vision of how to create, transform or improve it
• Negotiation (and communication): in order to reconcile business demand with development capacity to deliver a product that meets the needs of customers

If you’re familiar with scrum delivery methods the role description and skillset above probably won’t be new to you. However, often Scrum projects still encounter decision making challenges that impede development. Here are some flags to look out for:

• The Product Owner has been appointed by proxy: this may occur when the real decision maker can’t make time for the project and can lead to delayed decision making and/or misdirection in terms of setting the product vision
• The Product Owner makes decisions by committee: consulting on product and project vision is always a good thing but spending multiple hours in meetings discussing decisions that need made will impact sprint velocity
• The Product Owner isn’t really a Product Owner: this can occur because a Product Owner is simply appointed to the role because they are available or have a similar role already (e.g. a BA with bandwidth but no knowledge of the product)

The list above is by no means exhaustive but it’s a useful starting point for assessing how to resolve some of the common pitfalls. A recent Viderity retrospective identified ways to overcome these challenges and to avoid some of them when starting a project. Below are some of our findings:

• Clearly define and assign the Product Owner role upfront – this may include in the contractual agreement for the project and will benefit both parties by aligning expectations for the role sooner rather than later
• Coach and mentor new POs – initial sessions with POs to discuss roles and responsibilities across the team can help every team member understand its importance. Retrospectives can also be a useful forum to discuss improvements.
• Frame decision options for Product Owners: Scrum teams should proactively offer options to Product Owners when issues arise (e.g. a late requirement gets raised in a project). Issues come in all shapes and sizes. Once identified, often the next step is to consider the options to resolve them. Framing a number of options with related impact assessments will help the Product Owner make a more informed (and often faster) decision that will help unblock delivery
• Be flexible around Product Owners’ other commitments – this sounds intuitive but is worth highlighting. If the daily scrum doesn’t fit the Product Owner’s diary because of a school run – then move it!