Michelle Woodruff

17 September 2019

Scrum Is Not Scrum Without a Product Owner

Who Is Your Product Owner? Why Do You Need One?

If your team is using Scrum for the development of software products and services, and you can’t answer these questions, you might be missing the mark on a vital component of value-driven delivery.

In this article I’ll provide an overview of the Product Owner role, then focus on common pitfalls and best practices to help agile teams optimize value.

What Is a Product Owner?

The Product Owner (PO) is a member of the Scrum Team. Their mission is to maximize the VALUE of the product and the Development Team. They represent customers, users, business and IT stakeholders. They manage the Product Backlog, which includes defining and/or accepting Product Backlog Items (PBIs), prioritizing PBIs to achieve value, and making sure the backlog is visible and clearly understood.

Who Is the Product Owner?

Software companies or organizations that build software products for consumers (B2C) and other businesses (B2B) typically have an actual Product Owner job title. In these organizations, the Product Owner role is easier to understand. But Agile isn’t just for B2C and B2B product development. In other types of organizations following the Scrum framework, the Product Owner role is often misunderstood or even worse, overlooked altogether.

Regardless of the type of development or services provided, there is always a product and a customer. For example, your customer may be software development teams, operations, or customer facing service representatives. To optimize value, teams must embrace these concepts and designate a Product Owner. In IT Infrastructure, the PO role could be filled by an Infrastructure or Technical Architect; in Internal Use Software, it might be a Business Analyst and in IT Consulting Services, the job of a PO might fall to a Customer Domain Lead.

But don’t fall into the trap of considering technical and domain expertise alone when selecting a PO. The PO should have what is referred to as CRACK qualities:

• Committed - to the work and fully engaged
• Responsible - for the outcome
• Authorized - by the person responsible for funding to make decisions
• Collaborative - as a normal mode of interaction
• Knowledgeable - about the business domain and strategy

A gap in any one of these qualities can lead to anti-patterns that ultimately impact value.

Product Owner Responsibilities

So what exactly does a Product Owner do?

The Product Owner owns the following, in order of flow:

• Product Vision – Clear concise description of why and for whom the product is built, and the expected value of the product.
• Product Roadmap – High-level visual summary of the product’s strategic goals, typically spanning a year or less at a time. Communicates the the “why”.
• Product Backlog – List of all work items needed to achieve the product vision, including features, user stories, technical stories, and defects. The Product Backlog is prioritized by the PO, estimated by the Development Team, refined jointly at least once a week, and made visible to the Scrum Team and Stakeholders.
• Release Plan – Translation of the high-level Product Roadmap and Product Backlog into an actionable plan, typically spanning a quarter or less. Communicates the “what”.

The Product Owner is also an integral part of the Scrum Team, highly available to the Development Team, providing requirements clarity, ensuring customer and stakeholder engagement and feedback, supporting the Scrum Master in protecting the Development Team from external requests, and educating stakeholders on agile ways of working.

As a member of the Scrum Team, the PO contributes to the following Scrum events:

SPRINT PLANNING

The PO helps define the Sprint goal (high-level summary of what the team wants to accomplish during the Sprint), clarifies Product Backlog Items (PBIs) to support estimation, and prioritizes PBIs. The Development Team is responsible for estimating PBIs and deciding what goes into the Sprint.

SPRINT

The PO is available to further clarify requirements for the Development Team as needed. The PO is the only person that can cancel a Sprint, which should be very rare and with good reason.

SPRINT STANDUPS

The PO is not required to attend daily standups, but a good PO attends in order to (1) understand what’s going on in the Sprint, and (2) clarify requirements when needed (during the meeting if brief, or after the meeting if involved).

SPRINT REVIEWS

The PO invites the appropriate Stakeholders to the Sprint Review. The PO accepts or rejects user stories, and compares to the Sprint goal for the Stakeholders.

SPRINT RETROSPECTIVES

The Retrospective is intended for the Scrum Team, and the PO is part of the Scrum Team, so by default the PO should attend. If however the Scrum Master believes the Development Team will not feel safe being open about what went wrong in the Sprint with the PO present, the Scrum Master may ask the PO to refrain from attending. This may indicate that the PO has not established trust with the Development Team or is in a position of power as opposed to being an equal member of the Scrum Team.

Working with the Development Team: Dos and Don’ts

To succeed at maximizing the value of the product, the Product Owner must also maximize the value of the Development Team. Teams perform at their best when they are empowered and are supported by leaders who establish trust, safety and respect. Below are some of the essential dos and don’ts for Product Owners in working with the Development Team.

DO:

• Spend half of your time learning from and collaborating with customers, users, stakeholders
• Spend the other half of your time with the Development Team clarifying requirements
• Say what you want, not how
• Attend Standups to stay in tune with the work and to provide clarity
• Work with the Scrum Master to protect the Development Team from work that is not on the backlog
• Know how to say “No” to PBIs that don’t add value

DON’T:

• Contribute to or question user story estimates
• Change the Sprint Backlog during the Sprint
• Assign tasks
• Ask individuals on the Development Team for status

Product Owner Common Pitfalls

If unprepared, Product Owners and their teams risk falling into some common traps and will ultimately fail in their mission to maximize the value of the product. POs should pay special attention to avoid the following pitfalls.

LACK OF CLEAR PRODUCT VISION

The vision is the story that everyone believes in. It excites and aligns everyone involved. Knowing the big picture of why and for whom we are building something helps us to make the right decisions along the way. Knowing the vision is one thing, communicating it is another. Create an Elevator Pitch. Make a vision poster or flyer and hand them out. Come up with a catchy phrase that captures the why, who and benefit.

LACK OF KNOWLEDGE, EXPERIENCE

All too often the Product Owner role is assigned to someone that doesn’t have the breadth of experience and skills that are required. After all, the PO is expected to be a leader, visionary, inspirational motivator, communicator, negotiator, domain expert, and a collaborator across all stakeholders. B2B/B2C Product Owners need to know how to perform market research, and understand sales and marketing. All POs need to understand how to define value or ROI. That’s a pretty tall order if you ask me. You can’t become a unicorn overnight, so be transparent and lean on the experts until you become one yourself. Collaboration is essential to making informed decisions and building trust.

LACK OF EMPOWERMENT

The PO must be empowered to make decisions on behalf of the customer, user and business stakeholders. If someone of higher authority publically reverses the decisions of the PO, they undermine the PO and the value of the role.

POSITION OF POWER

The PO should be an equal member in the Scrum Team. The PO should never be a direct line manager over the Development Team.

UNAVAILABLE

The PO must be readily available to the Development Team to clarify requirements. There are multiple possible root causes of this common pitfall.

• PO is spending a greater amount of time with the customer and stakeholders than with the Development Team. Remember that the PO’s mission is to maximize the value of both the product and the Development Team. To do that, the PO has to spend time with and build trust with both the Customer and the Development Team. The PO has to communicate customer needs clearly to the Development Team, and communicate the Development Team’s capacity clearly to the Customer. Sit close to the Development Team if possible. Remember that face-to-face communication beats all other forms of communication. Bring them cookies! They are your friends.
• The PO has too many products and/or teams. A product should have only one owner. If the PO has too many products, this can be solved by offloading products to other POs. In the case where one product spans multiple teams, consider offloading some of the user story development and backlog refinement work to the Development Team, while providing visibility to the PO as the person accountable for the backlog.
• Being a PO is a part-time responsibility. The PO should be fully dedicated. Also be aware of the anti-pattern of having one individual fill both the Product Owner and Scrum Master roles. These roles are mutually exclusive and should not be combined.

DEADLINE FOCUSED

The focus should always be on value, not on deadlines. That doesn’t mean that deadlines are optional. We all know better than that. The task at hand is to deliver releasable product increments that provide the most value to the customer or end user within that time frame. The PO plays an instrumental role in enabling value-driven delivery by educating the customer, end user, and stakeholders on Agile ways of working, ensuring they are involved in Sprint reviews so they understand progress, are a regular part of the feedback loop, and are a part of the decision making process throughout.

POOR BACKLOG PRACTICES

It goes without saying that the Product Backlog if not defined, decomposed, and prioritized properly will negatively impact value. Here are some anti-patterns to avoid:

• The backlog is not aligned to the Product Vision and Product Roadmap. Make sure the Product Vision and Product Roadmap are clear. Use story mapping to help everyone visualize the backlog by function and priority.
• The PO is waiting until Backlog Refinement sessions to re-prioritize the backlog. This should be an ongoing exercise for the PO, that occurs outside of the Backlog Refinement meetings and during the meetings.
• User stories are not up to par. Consider the INVEST checklist below.
• Independent - stories can be worked in any order
• Negotiable - not a contract, rather an invitation to a conversation
• Valuable - the story has value to the “user” in the user story
• Estimable - well enough defined and decomposed to be able to estimate
• Small - ideally no bigger than a quarter of a Sprint or smaller
• Testable - can be tested by anyone, based on clear acceptance criteria
• User stories are being written at the product layer or architecture level. Keep in mind that the goal is to deliver a potentially shippable product increment at the end of each Sprint. Let’s say you are building a mobile shopping app. A good user story might be the ability to search for a particular service. A user story to design the end state UX is not a potentially shippable increment that provides value to the customer.
• Insufficient time being spent on backlog refinement. Backlog refinement is a Scrum Team activity. The Scrum Team decides how and when refinement is done. A general rule of thumb is that backlog refinement should consume 5-10% of the team capacity. Set this time aside in the Sprint backlog, and schedule refinement sessions at the same time each week. When a team is new to adopting Scrum, more time may be needed initially. Make sure that there are 2 to 3 Sprints worth of “ready-ready” PBIs in the backlog at any given point in time. And make sure that PBIs are decomposed or split so they are no bigger than a quarter of a Sprint.

Scrum without a PO is not Scrum. It is a required and necessary role. Most Scrum failures can be traced to a team that has a PO-in-name-only, or even worse, no PO at all.

Hopefully this article gives you some insights into the importance of this role and how to make it highly effective in your organization.