TL; DR: Product Owner Interview Questions — The Product Backlog and Refinement
If you are looking to fill a position for a Product Owner in your organization, you may find the following 71 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 8,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 Stefan in one of his upcoming Professional Scrum training classes!
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.
71 Product Owner Interview Questions
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 71-question-strong interview guide here:
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).
19 Product Owner Interview Questions on the Product Backlog, Refinement, Forecasts, and Estimates
Please find the following 19 of 71 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:
- What is the purpose behind the Product Backlog refinement?
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.
- How much time should you spend on Product Backlog refinement?
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.
- How would you organize the “refining” process of Product Backlog items?
In general, it is beneficial to structure the refinement process around questions such as:
- What items are no longer relevant?
- What items need to be split?
- What items can be updated with new information?
- Does this update change previous estimations?
- Has the priority of specific items changed?
- Do we have any new topics or learnings that haven’t yet been considered? (If yes, these need to be captured as new Product Backlog items.)
- How many Product Backlog items can you work on in parallel to ensure continued relevance to customers and the company?
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.
- You love using the Product Backlog as a kind of repository, adding ideas to continue working on them at a later stage. Over time, you have created over 500 tickets in various stages. What is your take: Can a Scrum Teamwork effectively on 500 tickets?
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.
- At what level do you include other team members in the refinement process?
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.
- How do you identify the value of a Product Backlog item?
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.
- How do you communicate to your team members the value of a backlog item?
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.
- What are good practices to order Product Backlog items?
Criteria to determine the order of a Product Backlog item, for example, are value, risk, work estimates, available expertise, and dependencies.
- How do you handle bugs and technical debt when many valuable new features are competing for resources?
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.
- Why is user story mapping a useful technique for Product Owners?
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.
- How do you best create Product Backlog items?
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.
- What shall a good user story look like? What is it structure?
For software development, the attributes of an exemplary user story are:
- The description is available,
- Acceptance criteria are defined,
- The story can be delivered within a Sprint,
- All UI deliverables are available,
- All (probable) dependencies are identified,
- Performance criteria are defined,
- Tracking criteria are defined and
- The story is estimated by the team. (I do believe that you cannot “not estimate” one way or another. Even the #noestimate approach includes a sizing model that is based on a kind of unspoken estimation.)
Product Owners should be familiar with Ron Jeffries Three-Cs—Card, Conversation, Confirmation—and Bill Wake’s INVEST principle.
- Where are you discussing user stories, only during refinement sessions?
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.
- What are typical pitfalls of the Product Backlog refinement?
Some of the typical pitfalls of a backlog refinement are:
- There are not enough refinement sessions, resulting in a low quality of the Product Backlog.
- There are too many refinement sessions, resulting in an overly detailed Product Backlog, resembling an upfront planning from the old waterfall planning ages.
- Turning requirement documents from stakeholders into user stories without involving the Scrum Team.
- Not involving the whole team in the refinement process, probably just the “lead engineer”.
- Not involving stakeholders.
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.
- Is it necessary to include detailed acceptance criteria with a user-story?
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.
- The Scrum Team requires time to investigate a technical issue with a user story to understand its requirements better. How do you continue with the refinement process of the particular user story?
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.
- One of your stakeholders presents you with such elaborate requirement documents that you copy them into Product Backlog items. Nevertheless, your Scrum Team is not pleased with this approach. Why is that?
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.
- When would you remove a feature?
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.
The Conclusion: Product Owner Interview Questions — The Product Backlog and Refinement
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.
✋ Do Not Miss Out and Learn about Product Backlog and Refinement: Join the 9,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.
71 Product Owner Interview Questions — Related Articles
Hiring: 71 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
