Stefan Wolpers September 27, 2021

Product Owner Interview Guide: PO Anti-Patterns

TL; DR: Product Owner Interview Questions: PO Anti-Patterns

If you are looking to fill a position for a Product Owner in your organization, you may find the following 82 interview questions useful to identify the right candidate. They are derived from my fifteen years of practical experience with Scrum and XP, serving both as Product Owner and Scrum Master and interviewing dozens of Product Owner candidates on behalf of my clients.

This latest update to the interview guide addresses Product Owner anti-patterns from Product Backlog management and refinement to the Sprint Review.

So far, this Product Owner interview guide has been downloaded more than 10,000 times.

🗞 Shall I notify you about articles like this one? Awesome! You can sign up here for the ‘Food for Agile Thought’ newsletter and join 33,000-plus subscribers.

🎓 Join Stefan in one of his upcoming Professional Scrum training classes!

Download the 82 Product Owner Interview Questions Ebook

The free 82 Product Owner Interview Questions ebook is not merely listing the questions, but also contains background information on:

• Why the questions are useful in the process, and…
• A range of appropriate answers.

Two to three questions from each category will provide more than enough ground for an engaging initial 60 minute-long conversation with candidates.

Cannot see the subscription form?
Please click here

The Role of the Product Owner According to the Scrum Guide

According to the Scrum Guide, Product Owners have a vital role in the value creation process of the Scrum team:

• Page 5: The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team. How this is done may vary widely across organizations, Scrum Teams, and individuals.
• Page 6: The Product Owner is also accountable for effective Product Backlog management, which includes developing and explicitly communicating the Product Goal.
• Page 6: The Product Owner is also accountable for effective Product Backlog management, which includes creating and clearly communicating Product Backlog items.
• Page 6: The Product Owner is also accountable for effective Product Backlog management, which includes ordering Product Backlog items.

Source: Scrum Guide 2020. (The aggregation is taken from the Scrum Guide 2020 Reordered.)

There is a reason why some refer to the Product Owner role as the “Achilles heel” of the Scrum team or the “single wringable neck.” Take out the Product Owner—by organizational design or choosing the wrong candidate—and Scrum mutates into a pretty solid waterfall 2.0 process.

Product Owner Interview Questions: The Organization of Questions and Answers

The ebook provides both questions as well as guidance on the range of suitable answers. These should allow an interviewer to deep dive into candidates’ understanding of Scrum and their agile mindset. However, please note that:

• The answers reflect the personal experience of the author and may not be valid for every organization: what works for organization A is probably failing in organization B,
• There are not suitable multiple choice questions to identify a candidate’s agile mindset given the complexity of applying “agile” to any organization,
• The author has a holistic view of agile practices: agile equals product discovery (what to build) plus product delivery (how to build it).

Please find the following an excerpt of the 82 Product Owner interview questions to identify suitable candidates for the role of Product Owner, addressing Product Owner anti-patterns:

PO Interview Questions Set 7: Product Owner Anti-Patterns

The seventh category of the Product Owner interview guide addresses PO anti-patterns from the management of the Product Backlog—including refining Product Backlog items—to the Sprint Planning and to the Sprint Review:

Product Backlog and Product Backlog Refinement

Question: What anti-patterns come to your mind when you think of the Product Owner’s responsibility to manage the Product Backlog?

Some of the typical Product Owner anti-patterns in handling the backlog are as follows:

• Storage for ideas: The Product Owner is using the Product Backlog as a repository of ideas and requirements. (This practice is clogging the Product Backlog, may lead to cognitive overload, and makes alignment with the ‘big picture’ at portfolio management and roadmap planning level very challenging for all participants, be it stakeholders or Scrum team members.)
• Part-time PO: The Product Owner is not working daily on the Product Backlog. (The Product Backlog needs to represent the best use of the Developers’ time at any given moment. Therefore, it needs to be “actionable” 24/7. Updating it once a week before the next refinement session or Sprint Planning does not suffice to meet this condition.)
• Copy & paste PO: The Product Owner creates user stories by breaking down requirement documents received from stakeholders into smaller chunks. (That scenario helped to coin the nickname “ticket monkey” for the Product Owner. Remember: Product Backlog item creation is a team exercise in most cases.)
• Dominant PO: Checks and balances: The Product Owner creates Product Backlog item by providing not just the ‘why’ but also the ‘how’ and the ‘what’. (The team answers the ‘how’ question – the technical implementation –, and both the team and the PO collaborate on the ‘what’ question: what scope is necessary to achieve the desired purpose.)
• Prioritization by proxy: A single stakeholder or a committee of stakeholders prioritizes the Product Backlog. (The strength of Scrum is building on the solid position of the Product Owner. The PO is the only person to decide what work items become Product Backlog items. Hence, the Product Owner also decides on the ordering of the Product Backlog. Take away that empowerment, and Scrum turns into a pretty robust waterfall 2.0 process.)
• 100% in advance: The Scrum Team creates a Product Backlog covering the complete project or product upfront because the release scope is limited. (Question: how can you be sure to know today what to deliver in six months from now—even if you believe you understand the scope today?)
• Over-sized: The Product Backlog contains more items than the Scrum Team can deliver within three to six Sprints, give or take. (This way, the Product Owner creates waste by hoarding issues that might never materialize.)
• Outdated issues: The Product Backlog contains items that haven’t been touched for six to eight weeks or more. (That is typically the length of two to four sprints. If the Product Owner is hoarding backlog items, the risk emerges that older Product Backlog items become outdated, thus rendering previously invested work of the Scrum Team obsolete.)
• Everything is estimated: All items of the Product Backlog are detailed and estimated. (That is too much upfront work and bears the risk of misallocating the Scrum Team’s time.)
• Component-based items: The Product Backlog items are sliced horizontally based on components instead of vertically based on end-to-end features. (This may be either caused by your organizational structure. Then move to cross-functional teams to improve the team’s ability to deliver. Otherwise, the Scrum team needs to strengthen their skills of writing user stories probably.)
• Missing acceptance criteria: There are work items in the Product Backlog without acceptance criteria. (While it is unnecessary to have acceptance criteria at the beginning of the refinement cycle, they would make the task much more manageable.)
• No more than a title: The Product Backlog contains item that comprise of little more than a title. (See above.)
• Issues too detailed: The Product Owner invests too much time upfront in creating Product Backlog items making them too detailed. (If a work item looks complete, the team members might not see the necessity to get involved in further refinement. This way, a “fat” item reduces the team’s engagement level, compromising the creation of a shared understanding. By the way, this didn’t happen back in the days when we used index cards given their physical limitation.)
• No research: The Product Backlog contains few to no spikes. (This often correlates with a Scrum team spending too much time discussing future problems instead of researching them hands-on as part of an iterative creation process.)
• What team? The Product Owner is not involving the entire Scrum Team in the refinement process and instead is relying on just the “lead engineer” (or any other member of the team independently of the others).

Sprint Planning Anti-Patterns

Question: What comes to your mind when you think of PO anti-patterns during Sprint Planning?

Some of the typical Product Owner anti-patterns during the Sprint Planning are as follows:

• What are we fighting for? The Product Owner cannot align the business objective of the upcoming Sprint with the overall product vision and the Product Goal. (A serious goal answers the “What are we fighting for?” question. It is also a negotiation between the Product Owner and the rest of the Scrum team to a certain extent. It shall be focused and measurable. The Developers’ forecast, the Sprint Goal, and the business objective go hand in hand.)
• No business objective, no Sprint Goal: The Product Owner proposes Product Backlog items that resemble a random assortment of tasks, providing no cohesion. Consequently, the Scrum Team does not create a Sprint goal. (If this is the natural way of finishing your Sprint Planning, you probably have outlived the usefulness of Scrum as a product development framework. Depending on the maturity of your product, Kanban may prove to be a better solution. Otherwise, the randomness may signal a weak Product Owner who listens too much to stakeholders instead of ordering the Product Backlog appropriately.)
• Unfinished business: UUnfinished Product Backlog items from the last Sprint spill over into the new Sprint without any discussion. (There might be good reasons for that, for example, a task’s value has not changed. It should not be an automatism, though; remember the sunk cost fallacy.)
• Last-minute changes: The Product Owner tries to squeeze in some last-minute Product Backlog items that are not ready yet. (Principally, it is the prerogative of the Product Owner to make such kinds of changes to ensure that the Development Team is working only on the most valuable tasks at any given time. However, if the Scrum Team is practicing Product Backlog refinement sessions regularly, these occurrences should be a rare exception. If those happen frequently, it indicates that the Product Owner needs help ordering the Product Backlog and communicating with the team. Or the Product Owner needs support to say ‘no’ more often to stakeholders.)
• Output focus: The Product Owner pushes the Developers to take on more tasks than they could realistically handle. Probably, the Product Owner is referring to former team metrics such as velocity to support their desire. (This behavior is a road to becoming a feature factory and deserves attention from the team’s Scrum Master. Furthermore, it violates both the Developers’ prerogative to pick Product Backlog items for the Sprint Backlog and Scrum Values.)
• No preparation: The Product Owner does not prepare the Product Backlog to provide valuable Product Backlog items in time. (Product Backlog needs to represent the best possible use of the Developers’ work from a customer value perspective at any given moment. In other words, your Scrum Team’s Product Backlog has to be actionable 24/7. By my standards, that means that you need to be capable of running a meaningful Sprint Planning instantly. Therefore, preparing a few basic Product Backlog items an hour before the beginning of the Sprint Planning is not enough.)

Sprint Anti-Patterns

Question: Could you please name some PO anti-patterns that might occur during the Sprint?

Some Sprint-related Product Owner anti-patterns are as follows:

• Absent PO: The Product Owner is absent most of the Sprint and is not available to answer questions of the Developers. (As the Sprint Backlog is emergent and the Developers may identify new work to achieve the Sprint Goal, this attitude might leave the Developers in the dark, risking the accomplishment of the Sprint Goal.)
• PO clinging to tasks: The Product Owner cannot let go of Product Backlog items once they become part of the Sprint Backlog. For example, the Product Owner increases the scope of a work item. Or, they change acceptance criteria once the Developers accept the issue into the Sprint Backlog. (There is a clear line: before a Product Backlog item becomes part of the Sprint Backlog, the Product Owner is responsible. However, once it moves from one backlog to the other, the Developers become responsible. If changes become acute during the Sprint, the team will collaboratively decide on how to handle them.)
• Inflexible PO: The Product Owner is not flexible to adjust acceptance criteria. (If the work on a task reveals that the agreed-upon acceptance criteria are no longer achievable or wasteful, the Scrum Team needs to adapt to the new reality. Blindly following the original plan violates core Scrum principles.)
• Delaying PO: The Product Owner does not provide feedback on work items once those are done. Instead, they wait until the end of the Sprint. (The Product Owner should immediately provide feedback on work items; that is essential for a good workflow with the team. Otherwise, the Product Owner will create an artificial queue within the Sprint, unnecessarily increasing the cycle time. This habit also puts reaching the Sprint Goal at risk.)
• Misuse of Sprint cancellation: The Product Owner cancels Sprints to impose their will onto the team. (It is the prerogative of the Product Owner to cancel Sprints. However, the Product Owner should not do this without a serious cause. The Product Owner should also never abort a Sprint without consulting the other team members first. Probably, the team has an idea of how to save the Sprint. Lastly, misusing the cancellation privilege also indicates a severe team collaboration issue.)
• No Sprint cancellation: The Product Owner does not cancel a Sprint whose Sprint Goal can no longer be achieved. (If the Scrum team identified a unifying Sprint Goal, for example, integrating a new payment method, and the management then abandons that payment method mid-sprint, continuing working on the Sprint Goal would be a waste. In this case, the Product Owner should consider canceling the Sprint.)

PO Anti-Patterns during the Daily Scrum

Question: Can you think of PO anti-patterns during the Daily Scrum since they do not have to attend the event?

By comparison to other Scrum events, the Daily Scrum is remarkably resilient to Product Owner anti-patterns. Nevertheless, some Product Owner anti-patterns during the Daily Scrum may be as follows:

• Planning meeting: The PO hijacks the Daily Scrum to discuss new requirements, refine new work items, or have a micro (Sprint) planning meeting.
• The talkative PO: The Product Owner actively participates in the Daily Scrum. (If allowed to participate, POs and stakeholders should listen in but not distract the Developers during their inspection and adaptation.)

Sprint Review Anti-Patterns

Question: What comes to your mind when you think of PO anti-patterns during Sprint Review?

Some common Product Owner anti-patterns regarding the Sprint Review are as follows:

• Selfish PO: Product Owners present “their” accomplishments to the stakeholders. (Remember the old saying: There is no “I” in “team?”)
• “Acceptance” by the PO: The Product Owner uses the Sprint Review to “accept” tasks/Product Backlog items. (A feedback loop—did the Developers deliver the agreed-upon functionality?—is valuable and should be decoupled from the Sprint Review. The Product Owner should communicate with the Developers whenever needed or when work items meet the Definition of Done.)
• Unapproachable PO: The Product Owner is not accepting feedback from stakeholders or the Developers. (Such “living in their PO bubbles” approach violates the prime purpose of the Sprint Review event.)

📖 Related Posts

54 Scrum Master Interview Questions to Identify Suitable Candidates.

Product Owner Anti-Patterns — 31 Ways to Improve as a PO.

Peer Recruiting: How to Hire a Scrum Master in Agile Times

The Scrum Guide Reordered — understand the Scrum Guide’ patterns and concepts quickly to avoid hiring imposters.

✋ Do Not Miss Out: Join the 10,000-plus Strong ‘Hands-on Agile’ Slack Team

I invite you to join the “Hands-on Agile” Slack team and enjoy the benefits of a fast-growing, vibrant community of agile practitioners from around the world.

If you like to join now all you have to do now is provide your credentials via this Google form, and I will sign you up. By the way, it’s free.

📅 Scrum Training Classes, Workshops, and Events

You can secure your seat for Scrum training classes, workshops, and meetups directly by following the corresponding link in the table below:

See all upcoming classes here.

You can book your seat for the training directly by following the corresponding links to the ticket shop. If the procurement process of your organization requires a different purchasing process, please contact Berlin Product People GmbH directly.