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 fourteen years of practical experience with XP and Scrum, serving both as Product Owner and Scrum Master and interviewing dozens of Product Owner candidates on behalf of my clients.
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 30,000-plus other subscribers.
Join more than 145 peers from May 27-29, 2021, for the Virtual Agile Camp Berlin 2021, a live virtual Barcamp using open space technology principles and practices.
Scrum is not a methodology but a framework. There are no rules that apply to each scenario, just good practices that have worked in other organizations before. Hence, you have to figure out on your own what is working for your organization. Finding this answer is a process and not a destination.
The role of the Product Owner itself is making the hiring process difficult to handle. The Product Owner is the least well-defined accountability within the Scrum framework and—at the same time—the one Scrum role with the most facets. (Please note that I will continue using ‘role’ on occasions throughout this document, although the Scrum Guide 2020 now speaks of ‘accountabilities.’)
A Product Owner is an innovator at heart and thus a value creator for customers and organizations if given a chance to work in an agile manner. The Product Owner is also the most vulnerable Scrum role. Turn them into a [fill-in a ticket-system of your choice] monkey or deprive them of the ability to say ‘no’—as in being the guardian of the Product Backlog—, and the Product Owner quickly becomes the Achilles heel of any agile organization.
The Product Owner role depends on the size of an organization, the industry it is operating in, its culture, and the lifecycle stage of that organization’s product(s). Lastly, there is an overlap with the product manager role. (Spoiler alert: they aren’t identical.)
The following interview questions are neither suited nor intended to turn an inexperienced interviewer into an agile software development expert. But in a seasoned practitioner’s hands, they support figuring out who of the candidates has been successfully working the agile trenches in the past. Remember, “Agile” is a mindset, not a methodology. Hence, no checklist can drive your recruiting success to the desired outcome.
Download your free copy of the 82-question-strong interview guide here:
Cannot see the subscription form?
Please click here
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:
Please find the following 19 of 82 Product Owner interview questions to identify suitable candidates for the role of Product Owner, addressing the Product Backlog, Product Backlog refinement, work items, forecasts, and estimates:
The refinement is a continuous process to create actionable Product Backlogs that allow a Scrum Team to have a Sprint Planning at a moment’s notice.
The Scrum Team accomplishes this level of preparedness by regularly refining Product Backlog items in small groups or with the whole Scrum Team, and not just once every Sprint as part of the Sprint Planning. The idea behind the refinement is to create a shared understanding with all team members, why a particular work item is valuable, what the Developers shall create, and how to realize the work item technically.
While the Scrum Guide 2020 drop the previous guidance on the time allocation, it remains a practical rule of thumb that the Scrum Team should reserve up to 10% of its time for the Product Backlog refinement.
In general, it is beneficial to structure the refinement process around questions such as:
It depends on several issues, such as the balance between stakeholder communication, customer research, and the Product Owner’s commitment to their Scrum Team. Working on more Product Backlog items than the team can handle in two to three Sprints at the same time might prove to be difficult, though. Often, if Product Owners cannot allocate sufficient time to a single item, they waste resources on half-baked work items of a questionable value.
From my experience, any Product Backlog that is larger than the scope of three or four Sprints is barely manageable if you want to maintain an actionable Product Backlog. Misusing a Product Backlog by adding hundreds of items to it is a clear sign that the Product Owner needs help from the Developers and the Scrum Master to better cope with the influx of ideas, suggestions, and requirements to avoid misallocating resources.
Lastly, beware of appeasing nagging stakeholders by merely adding their “requirements” to the Product Backlog. This does not solve the issues; it just postpones the inevitable discussion as the stakeholders will now expect that the Scrum Team will create their Increment.
When the foundation of a Product Backlog item is ready for that. The readiness isn’t easy to generalize since it depends on the nature of the product itself, the Scrum Team’s experience, and the organization’s leadership style.
From my experience, this influences the readiness and availability of a Scrum Team to contribute to the refinement process effectively. For creating a shared understanding of the why, what, and how of a work item among all team members, the precise moment of involvement is crucial. If the team is involved too early, the Developers may consider this a waste of their time. If the Scrum Team is involved too late—for example, all specifications have already been prepared—, they may feel not respected. If in doubt, the Product Owner should include the Scrum Master in the process.
Some proven categories to define value are projected revenue increase, cost cutting effects, a projected growth of the customer base, and an increase in customer satisfaction rates.
More metrics are available from Scrum.org’s Evidence-Based Management model.
Product Owners communicate value with any information suitable to further the Scrum Team’s understanding. That communication can be quantitative, such as analytical data describing how a process is utilized, financial projections, an increase in conversion rates, acquiring new customers, etc.) It can also be qualitative, such as transcripts, screencasts, or videos from a user testing session.
Preferably, the Scrum Team members already know in advance as they are regularly participating in user research activities.
Criteria to determine the order of a Product Backlog item, for example, are value, risk, work estimates, available expertise, and dependencies.
Focusing solely on shipping new features is a slippery slope that quickly leads to the build-up of technical debt. You trade a short-term win—shipping more features—for a long-term liability. Technical debt will inevitably slow down the creature of new Product Increments in the future, probably to a point where the product seems to be at a standstill.
In other words: By accruing technical debt, the very purpose of becoming agile—learning faster as an organization than the competition, thus being able to exploit market opportunities—is at stake.
Hence it is a good practice to allocate around 20 percent of the Scrum Team’s capacity to keeping technical debt at bay at any given time. Experienced Product Owners support this long-term thinking.
User story mapping a great way to visualize the "big picture" within a Product Backlog. Additionally, user story mapping is an instrumental means to improve communication with stakeholders and the Scrum Team. These workshops create a shared product understanding across teams, roles, and departments.
The best way to create Product Backlog items, particularly user stories, is a collaborative and iterative approach, using collective inspection and adaptation, including the whole Scrum Team. User story creation should not blindly follow a specific template but rather be a lively negotiation with the team, focusing on reaching a shared understanding of “why,” “what,” and “how” with all team members.
For software development, the attributes of an exemplary user story are:
Product Owners should be familiar with Ron Jeffries Three-Cs—Card, Conversation, Confirmation—and Bill Wake’s INVEST principle.
The best way to discuss a user story is by doing so synchronously with all involved team members to ensure that a shared understanding is created. This approach works for co-located as well as distributed Scrum Teams.
Asynchronous discussions may be an option when team members cannot participate in a discussion or when the Product Owner is in the field, and feedback is required.
It would help if you avoided, though, lengthy discussions via comments on tickets. That’s a sign of a weak refinement process as it creates unnecessary queues of idleness.
Some of the typical pitfalls of a backlog refinement are:
This open question is an invitation to Product Owner candidates to share from their previous experience and how it influenced their current understanding of proper Product Backlog management.
There is an extensive list of anti-patterns available in the following article: 28 Product Backlog and Refinement Anti-Patterns.
Generally, acceptance criteria define the functional and non-functional requirements that need to be met. The level of detail may vary depending on the nature of the task. Hence, it is a good practice to include the Scrum Team in their creation as some of those requirements may already be addressed by the team’s Definition of Done.
Borrow from XP and run a spike during the next Sprint. Once the team can provide better insights to its technical side, come back to the user story, and resume the refinement.
Product Backlog items are a token for discussion to create a shared understanding and secure the Developers' buy-in. If the Developers are not involved in devising, disseminating, and capturing these, they do not see any ownership in such work items. This likely results in a lower level of engagement, which may negatively affect the value created for customers.
The best way to “remove” useless features is not to build them in the first place. Simplicity and radical focus on value delivered to customers is key to any successful agile product organization.
Should—despite all validation efforts during product discovery—a feature of lesser value slip into the Product Backlog and be delivered, it should be removed as soon as possible from the live product. The same applies to an existing feature that has outlived its usefulness.
Scrum has always been a pragmatic business, and to succeed in this mindset, candidates need to have a passion for getting their hands dirty. While the basic rules are trivial, getting a group of individuals with different backgrounds, levels of engagement, and personal agendas, to continuously deliver value by creating a great product is challenging. The larger the organization is, the more management level there are, the more likely failure in one of its many forms is lurking around the corner.
The Product Owner interview questions are not necessarily suited to turn an inexperienced interviewer into an agile expert. However, they support figuring out what candidate has been working in the agile trenches and who’s more likely to be an imposter. (You should avoid inviting candidates from the latter category to a trial.)
Hence it’s probably a good idea to look for a pragmatic veteran who has experienced failure—and success—in other projects before and the scars to prove it.
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.
Hiring: 82 Scrum Product Owner Interview Questions to Avoid Agile Imposters
28 Product Backlog and Refinement Anti-Patterns
Product Backlog Defense – Common Patterns of Stakeholder Interference
A Forensic Product Backlog Analysis — Making Your Scrum Work
Product Backlog Anti-Patterns Q&A
Product Discovery Anti-Patterns Leading to Failure
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.
TL; DR: Technical Product Ownership Dive deep into the benefits—or the lack thereof—of the technical…
TL; DR: System-Level Scrum Stakeholder Anti-Patterns Learn how outdated organizational structures manifest themselves in system-level…
TL; DR: Scrum Master Tasks: Let's Bust Some Myths! Rumor says that a great Scrum…