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 sixteen 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 34,000-plus other subscribers.
🎓 Join Stefan in one of his upcoming Professional Scrum training classes!
The free 82 Product Owner Interview Questions PDF is not merely listing the questions, but also contains background information on:
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
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.
The Product Owner interview questions in this PDF are modeled after a holistic model of agile product development for software products:
In this model, product discovery is moved as far as possible to the left to keep costs of validating hypotheses—derived from a vision and strategy—low and increase the speed of experimentation. In this approach, the Product Owner needs to coach the Scrum Team on how to adopt such a holistic model, teaming up with the Scrum Master in the process.
Therefore, the PDF contains additional background and contextual information, how the following set of questions can be interpreted as well as guidance on desired or acceptable ranges of answers for each question. The questions themselves are grouped into six categories.
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 82 Product Owner interview questions to identify suitable candidates for the role of Product Owner:
This category addresses the meta-level of the Product Owner role and the Scrum process. Please keep the following in mind when asking the questions:
As the “Manifesto for Agile Software Development” states, it is mainly about adaptability over following a plan. Or, to put it with Peter Drucker, it is about doing the right things, and less about doing the things right. Concerning product development, being agile is about postponing deciding to invest in the latest economically feasible moment. This is achieved by testing hypotheses as fast and as inexpensive as possible, thus mitigating risk and maximizing the development team’s work. It also means to have the courage to stop an effort in case the chosen course is no longer viable.
This is an open-ended question better to understand the candidates’ perception of their role. A Product Owner is a leadership role, yielding no authority in a traditional management sense. In that way, the Product Owner is featured a bit by all the labels mentioned in the question. The Product Owner role has also been dubbed as “bottleneck” or the “Achilles heel of the Scrum process”; any mentioning of that would undoubtedly be a plus. If a candidate is mostly referring to something like “I am the one creating the user stories,” I would dig into that.
Full-stack “product people”—covering the product manager & Product Owner role in one person—are rare. Often, it takes too much time to cover all responsibilities: from communication to stakeholders and customers to organize the operational work within the Scrum process. Depending on the product, Product Owners hence can quickly spread themselves too thin to become a meaningful player in the process. (Speaking of which: a Product Owner is not a requirements engineer, not a business analyst, and not a user stories expert either.) As a result, you may observe that large organizations split the responsibilities among two or more individuals. Here, the product manager is often responsible for strategic aspects, while the Product Owner is a more tactical role. For smaller or less complex products, Product Owners may very well cover both roles simultaneously.
There is a fine line between a product manager and a Product Owner role, and it depends on how the role is crystallized in the company's structure and culture. Usually, besides product management duties, Product Ownership entails establishing the product vision and strategy, its alignment with the company's goals and objectives, and managing any internal and external stakeholders in this process.
Saying “no” is an essential qualification—and empowerment—for each Product Owner. For example, it is required to protect the team from a stakeholder’s pet project of a doubtful value. Or to put an end to silo thinking and local optimization within the organization. Product owners create value by shipping the right product and maximizing the amount of work deliberately not done. Because of that, the organization has to respect a “no” from them. Otherwise, they will not fulfill their role: maximizing the product's value across the whole organization. Applying “Scrum” without an empowered Product Owner creates a great “Waterfall 2.0” process. The Product Owner’s empowerment to decide over the Product Backlog can therefore act as a litmus test of the organization’s adoption of agile principles.
Suppose a person or a group of individuals, for example, a product council, exercises control over the Product Backlog. In that case, you're not a Product Owner but a proxy. You're probably more a product manager that happens to work with an agile team that uses a subset of Scrum. That may work fine, depending on the organization's nature, culture, and product. But it cannot be called Scrum.
CEO of the product, product visionary, strategic thinker, servant leader w/o authority, entrepreneur/intrapreneur, innovator, systems thinker, single wringable neck.
Early, often, respectfully, transparently, being available regularly, and responding with adequate speed and attention. As the Scrum Guide 2020 states: “The Scrum Team is responsible for all product-related activities from stakeholder collaboration, verification, maintenance, operation, experimentation, research and development, and anything else that might be required.”
Self-organization is at the core of any serious agile framework, Scrum included. Suppose a candidate feels uncomfortable with the concept that the Scrum Team or the Scrum Master have ideas on how product discovery and delivery might improve in the future. In that case, you should dig deeper into that. It’s not a good idea to substitute silos at the department level with “functional silos” within Scrum, when communication, sharing ideas and creating a shared understanding are paramount for Scrum Team’s success.
The best way of collaboration for PO and Scrum Master is embracing Scrum Values. Both serve in leadership roles without yielding any authority. Both depend on each other for the Scrum Team’s success, for example, accomplishing a Sprint Goal. They are both also allies concerning coaching the organization to become agile. Daily, the Product Owner is responsible for promptly providing feedback on product matters, clarifying goals, and ensuring that everyone on the Scrum Team understands the product vision. The Scrum Master, in return, needs to support the Product Owner in building an actionable Product Backlog while facilitating an effective collaboration within the Scrum Team in general.
Generally speaking, in an ideal world, the members of a cross-functional team cover all skills that are required by the Scrum Team to deliver value to customers independently. This may work for a product at an early stage when one team is handling everything. When the organization needs to scale, dealing with interdependencies—here: other teams—becomes a necessity. Depending on that, the actual composition of a team highly depends on what the team is delivering. Typical roles in cross-functional teams are business or data analysts, UX and UI designers, Developers (front-end, back-end), QA Developers, and probably DevOps engineers.
The Product Owner is expected to participate in all events: Daily Scrums, Sprint Planning, Sprint Review, and Sprint Retrospectives. Otherwise, the Product Owner cannot answer possible questions quickly, and impediments cannot be solved in a timely fashion, which would contradict the core of being agile.
Absolutely. Or, to cite Lewis Carroll: “If you don’t know where you’re going, any road will get you there.” The agile product stack starts with the vision and strategy of the company. It then is broken down into a product portfolio—where applicable—and the product roadmap for each service and product, and ends with the corresponding Product Backlogs and Sprint Backlogs. The Product Owner needs to be familiar with all levels of the agile product stack.
This question deals with how Product Owners can mitigate the risk they pose to the Scrum Team. Often, they slow down the team because the Product Backlog management process is insufficient. There might be several reasons for that: Product Backlog items are created shortly before a Sprint is supposed to start. Or work items do not meet quality standards, as they cannot allocate enough time for their creation and refinement. Beyond the Product Backlog management, they might not be available on short notice to answer questions during a Sprint. A useful way of Product Owner risk mitigation involves the other Scrum Team members at an earlier stage. Or they are encouraging collective ownership of the product by the Scrum Team. This approach is much supported by creating a shared understanding of goals at the team level. (Start with the “Why are we doing this?”)
Adding user stories to the Product Backlog merely proves that the PO can handle the ticket system. Measuring real value to customers, however, requires a different approach. Suitable KPIs of the Product Owner’s contribution to the team would focus on the outcome, not output. Examples of such metrics are the lead-time from idea to an available feature, cycle time for valuating ideas, or NPS scores. (Learn more about Evidence-Based Management for Product Owners.)
This category of the Product Owner interview questions is branching out into the areas of product discovery and product management:
Lean UX, Lean Startup, Design Thinking, or Service Design are other agile practices that are much better suited for product discovery than Scrum. All that Scrum refers to is that the Product Owner is accountable for managing the Product Backlog. Supposedly, the Product Owner is the individual who knows what is valuable at any given time. But Scrum doesn’t elaborate on how the Product Owner gains this insight.
Here, Product Owner candidates should explain their ideas of a product discovery process: From idea, via hypothesis, and experiment and validation. There are various ways to come up with ideas: Through analyzing market needs, industry trends, your data (analytics, NPS, etc.), and the competition. Also, regular sessions with stakeholders, such as sales and customer care, and the Scrum Team(s) tend to be fruitful. Empowering team members to spend a part of their work-time on new ideas is also a powerful practice. (Think of Gmail.) Most importantly, observing customers regularly by running continuous user tests is an effective way of gaining insights for new features, products, and services. This approach is even more useful when the whole Scrum Team actively participates in the process.
The candidate should name a few of the leading agile frameworks, such as Jobs-to-be-done, Lean UX, Lean Startup, Design Sprints, Service Design, design ethnography, and lean user testing, NPS, Voice of the Customer, and others.
User research, or better: user testing, should be a continuous, regular exercise in any product-driven organization. It’s a vital part of the agile build-measure-learn cycle. Practically, this means that communicating with UX designers and researchers becomes an integral part of the work of the PO and the entire Scrum Team. (Ideally, they belong to the team itself.) Also, customer feedback is continuously gathered by running frequent user interviews and observations. Moreover, these ideas also apply to technical projects, for example, API services.
Spending 50 % of their time with customers would be great. However, if it’s less than 10 %, and if no one else is handling product discovery on behalf of the Product Owner, the product discovery process needs to be improved. For example, by relieving the PO from administrative tasks, such as user story writing. (Note: the Product Owner is not primarily a user story author.)
Actively involving stakeholders and members of the general organization in the product discovery process is a sound approach. People like to have a purpose in life and be a part of something larger than themselves. So, providing a possibility to contribute to everyone without regard for their position in the organization will make working as a PO easier. A process for this level of inclusion doesn’t require fancy technology. A simple, shared spreadsheet or form is enough to kick-start it. An initial template to suggest new product features could comprise questions that address the why, the what, and the for whom. It could handle the tactical or strategic nature of the suggestion, a possible time-frame, or an estimate of the expected return on investment. Most importantly, designing the process should be kept agile: start with a simple solution, then improve it once the first experience has been made.
It is highly recommended to involve the Scrum Team as early as possible in the product discovery process. There are mainly three reasons for that practice: (1) The sooner the Developers participate in the product discovery process, the lesser the chances are that solutions are pursued that are technically not viable or would not result in a return on investment. (2) An early involvement ensures that the Product Owner and the other Scrum Team members develop a shared understanding and ownership of what they will build. This helps significantly allocate resources to the right issues, maximize the customer's value, and mitigate the investment risk. (3) Developers' early involvement also ensures their buy-in, a higher commitment level, and the Scrum Team's willingness to participate in all product development phases. This will provide additional motivation on the Scrum Team's side to participate in any change needed to accomplish the goals defined for each Sprint/product release.
There are quantitative and qualitative categories, such as revenue increases, cost-cutting benefits by internal process improvements, increased customer satisfaction rates (NPS), sign-ups from customers for new products, positive customer feedback in customer care, etc. With this open question, Product Owner candidates should demonstrate their knowledge of determining what content constitutes an actionable Product Backlog, maximizing the value of the Developers' work on behalf of the customers. It opens the area of product metrics broad. It allows for a discussion of outcomes vs. outputs, the escape from the feature factory, and how to overcome the industrial paradigm in general.
Product Owners can avoid misallocating resources by a firm decision at the moment when it is clear that a product or feature is not valuable or not feasible. This means that a continuous monitoring process, such as metrics or regular user tests, needs to be established. Once the build-measure-learn cycle provides proof that an idea or a product is unlikely to succeed, the resource allocation needs to stop. (Don’t allow the “sunk cost” fallacy to cloud your judgment: no matter how much has been already spent, it does not justify to continue working on the product.)
There are several stages in which a Product Owner should participate, starting at the portfolio level to the product stage, to the release planning, and the Sprint Planning. Participation during the vision and strategy stages is highly recommended, though.
This category of the Product Owner interview questions deals with specific aspects of relationships of the Product Owners with internal stakeholders:
A good starting point would be working with the “Manifesto of Agile Software Development,” particularly ensuring that stakeholders understand that adapting to change over following a plan is paramount for the organization’s future success. Stakeholders also need to understand that “requirements” (and thus probably local optimizations efforts) are no longer a valid form of the product delivery process. Instead, continuous product discovery and iterative and incremental product creation become the guiding principles, elevating experiments, and accepting failure to good practices. Becoming agile means competing with other—probably more valuable—product ideas for scarce resources and accepting that the PO is the gatekeeper to the Product Backlog. It means that there are no more arbitrary delivery dates, but delivery intervals, projecting the knowledge of today into the future. Lastly, stakeholders will need to understand the magnitude of abandoning the command & control management style and empowering autonomous and self-organizing teams for product delivery.
Communication and transparency are critical to effective collaboration with stakeholders. There are various ways to establish and improve this communication over time. For example, institute regular meetings with each stakeholder or have stakeholders name product ambassadors, who then act as “liaison officers” and train them accordingly. Arrange workshops with stakeholders and ambassadors, and ask your Scrum Master and the Developers to join the effort. Team up with the user experience people and run, for example, user journey or user story mapping workshops. Or invite stakeholders to Product Backlog refinement sessions to explain a user story's value to the rest of the Scrum Team. Sprint Reviews and user interviews are also well suited to improve collaboration and communication over time.
An often promising way to deal with uncooperative stakeholders is to win them over by demonstrating the value of agile product development. Early in the transition process, it is advisable to educate them with product-related workshops on agile principles. Proven examples are user story mapping or product roadmap planning workshops. (It is recommended to secure the help of an experienced coach at this stage.) It has also proven to help establish a close communication schedule with the stakeholders, for example, by having regular meetings. Also, educating members from stakeholder teams to act as “liaison officers” to the product organization significantly improves cooperation. It mitigates the usual feeling of losing control on the stakeholders’ side. At a later stage, typical agile events, such as Sprint Reviews, also work well by demonstrating what value the Scrum Team created for them. Generally, it is a process that will take time, and there are no shortcuts available. As a last resort, if everything else hasn’t worked out, the PO might need support from a C-level sponsor. (Read more: 11 Proven Stakeholder Communication Tactics during an Agile Transition.)
Agile first principles require to adapt to change over executing a plan in the first place. If a project is late, it probably has lost some of its original value to the organization and its customers. In this case, reevaluating its benefit before pouring more resources into it is a necessity. If the project still delivers value, you should probably go for it. Keep in mind that there is always competition from the other investment opportunities comprising the Product Backlog. However, continue building it merely because of the prior investment means that the stakeholder has fallen for the sunk cost fallacy.
Submit the pet project to the usual, standardized process that every product idea has to master. Just continuously update the business case behind such a pet project and have it compete with valuable projects. Sooner or later, common sense will end this kind of misallocation of resources, as pet projects rarely provide a return on investment. Other stakeholders with valuable projects make good allies in this conflict.
This problem is generally comparable to the pet project problem and could be dealt with accordingly. However, the distinguishing factor, in this case, is the urgency and probably the party’s different status that’s demanding the features. In a sales-driven organization, the sales team can often secure sponsorship from the C-level for such suggestions. This tends to happen when sales forecasts are missed. In this situation, the Product Owner can often only rally support from other stakeholders to fight off the demand based on opportunity costs. If the usual process is overridden by executive intervention, the Product Owner needs to address this issue immediately. You can’t have the (agile) cake and eat it, too.
Usually, this kind of attitude is encouraged by the management in pursuit of meeting sales targets. It reflects a non-agile, opportunistic mindset that values instant gratification—more sales—over a sustainable product development strategy. To change this mindset, it certainly helps to reach out to the sales department and offer them support on the sales process's technical side as early as possible. However, given the sales team's usual incentives, a real change will only happen if the management buys-in to agile product development principles. These might include an adaptation of the remuneration scheme for sales.
Providing an idea management system is a good starting point. This can be a simple template for the suggesting party covering the what, why, when, for whom, and ROI questions. Start communicating with the person in question throughout the evaluation. If a suggestion is accepted for realization, include the suggesting person in the following process. (For example, invite the individual to a user story mapping workshop or user tests.) Lastly, provide continuous feedback throughout the whole development and delivery cycle with regular checkpoints against the original targets. Finally, 3-12 months after shipping, update the stakeholder whether the expectations—for example, ROI, cost savings, engagement, and other KPI—have been met out in the field.
The questions in this set concern one of the most contentious topics in the profession: “How do we build agile product roadmaps that work?”
Yes, it would significantly impede the Product Owner's work, as transparency is required to innovate most effectively within an organization. Nowadays, innovation is a team sport. The brilliant individual—creating great innovations single-handedly—is a myth. (Not even Mr. Jobs considered himself to be such an individual.) Such a joined team effort always starts with a shared understanding of product vision and strategy.
No, that practice is not anachronistic at all. A product portfolio encompasses strategic objectives and goals at the company level. These endeavors are related not only to the overarching goal. They are also associated with their sustainability from a financial point of view. One initiative, for example, can act as a source of investment for another one. Or all these endeavors have a common investment source. A portfolio plan helps structure investment sources, thus contributing to better financial management while illustrating business value sources.
In general, you would consider a top-down approach, starting with the company goals and the general product vision. Once several iterations with the leadership and stakeholders have been performed, it is usually advisable to combine the first draft with a bottom-up initiative. Meeting somewhere in the middle guarantees those crucial aspects, while probably of a more detailed nature, aren’t lost in the process.
Product roadmap planning is a continuous exercise to analyze products at all stages: live, in development, under planning, or on the brink of being phased-out. Depending on the organization's maturity, the size of the product portfolio, its products and service, the industry, and its level of regulation, this can be a quarterly or even monthly practice.
The recommended way to achieve this goal is to include the Scrum Team in the product discovery process actively. Suppose Developers are merely confronted with requirement documents. In that case, they rightfully feel disrespected, as they only have limited options to become self-organized as they are told what to do. (Which leads to a cog-in-the-machinery syndrome, tempering with their idea of autonomy.) There are various ways how the Product Owner can include the Developers in the product discovery process, for example, by user story mappings with other stakeholders, inclusion in the portfolio and product roadmap planning, participation in user tests, to name a few.
Usually, it's the internal stakeholders, Scrum Team members or their representatives, and the Product Owners. Adding customers to the mix is a bonus.
As a rule of thumb, 50% are supposed to be allocated to stakeholder communication of all kinds.
A Monte Carlo simulation is an algorithm-based statistical approach to obtain numerical results. Product Owners can use this approach to forecast probable delivery windows of releases or features based on the previous Scrum Team performance. (This question opens the discussion on how to deal with deadlines, forecasts, and other legitimate inquiries of stakeholders regarding product delivery.)
This category of the Product Owner interview questions covers the Product Owner’s home turf: the Product Backlog, its refinement, and work item creation:
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.
The sixth category that addresses the Sprint itself:
It is a negotiation with the Scrum Team. The answer depends on the team’s situation and experience: If the designers are likely delivering—they have always kept their promises in the past—, and the Developers could accomplish the user story nevertheless within the Sprint, and the Developers agree with the situation, it is probably an acceptable exception.
Ultimately, the Scrum Team’s decision is whether to pick the work item for the next Sprint.
That is unacceptable behavior, as the Developers are self-organizing. Hence distributing tasks among themselves is their prerogative.
Let’s have a closer look at the Sprint Planning:
The Product Owner presents the business objective of the next Sprint to the Scrum Team. Collaboratively, the Scrum Team creates the Sprint Goal. The Developers then pick— considering all circumstances, for example, available capacity—those Product Backlog items they deem necessary to achieve the Sprint Goal. The presence of the Product Owner during this part of the Sprint Planning is essential.
Often, the Developers now add details to the Sprint Backlog items, for example, splitting them up into tasks, identifying parts that need further clarification, or agreeing on who will be working on what tasks. Product Owners do not necessarily need to participate in this part of the Sprint Planning. But they need to be on stand-by for additional questions.
By all means, yes. That way, the Product Owner can answer quickly, thus avoiding unnecessary delays.
Trust is the beginning of all. And the Developers do not trust the process, or the line management, or the stakeholders. This mistrust might be rooted in the organization's culture, a former experience, or the work item's quality. The team might also be too junior to understand some work items' implications fully. Or the product is suffering from technical debt, which makes estimates generally more volatile.
The candidate should name some reasons for the behavior and suggest joining with the Scrum Master to provide the team with a path to let this habit go. The issue would make an outstanding topic for the Sprint Retrospective.
This kind of stakeholder behavior is not acceptable. It is the Product Owner’s objective to understand the scope of a feature request in advance clearly. Sneaking in features through the backdoor a typical Scrum anti-pattern that needs to be investigated and addressed.
This question opens the discussion on how to deal with selfish stakeholders, particularly in organizations that haven’t yet fully embraced the Product Owner concept.
The Scrum Guide is not explicit about this situation. On the one side, the Scrum Team decides on when to release what Increment to the customers. On the other side, the Product Owner is “is accountable for maximizing the value of the product resulting from the work of the Scrum Team.”
This question opens the discussion on Scrum’s built-in checks and balances and how effective collaboration within the Scrum Team might work.
The Scrum Team decides on when to release what Increment to the customers. There is no automatism for the release.
It is not the Product Owner’s task to organize the Sprint Review, but the whole Scrum Team should be eager to experience it. The Sprint Review is a critical opportunity to inspect the previous Sprint’s outcome and adapt the Product Backlog to serve the customers with the next Sprint best.
This behavior is undoubtedly an anti-pattern of a successful Scrum Team as it violates several Scrum principles, for example, providing transparency or adhering to openness and respect.
First of all, Developers should never work on items the Product Owner does not know. Bypassing the Product Owner in that respect shows a significant deficit in understanding Scrum basics and should immediately be addressed in collaboration with the Scrum Master. (Learn more: Gold-Plating Beyond Done — Making Your Scrum Work #7.)
Absolutely, Product Owners are members of the Scrum Team. Hence they participate in the Sprint Retrospective.
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:
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:
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:
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:
Becoming an agile, learning organization focused on creating customer value is about developing a product mindset everywhere, from the individual to the C-level. Employing Scrum can be a major stepping stone on this journey when the management empowers Product Owners and is not merely regarding Scrum as a delivery means to ship more features, products, and services within the constraints of the iron (project) triangle.
Again, a fully formed and empowered product owner is crucial for a transformation success at that level. The following set of questions regarding the product mindset is designed to better understand a candidate’s perspective: Do they probably have what it takes to fill the shoes of the Product Owner role?
Looking back at your professional experience, can you name some first principles of a Product Owner with a product mindset?
This question allows the Product Owner candidate to reflect on their core beliefs of product management in general and the Product Owner role in particular. My top three choices of the first principles of the product mindset are:
You have worked with Product Owners (and product managers) in the past. How did the successful ones master the challenges of the role? Moreover, where did the less successful ones fail?
In my experience, successful Product Owners manage to split their time between different responsibilities and stakeholders without getting lost in details or failing to communicate appropriately while guiding everyone in the right direction: Accomplishing the product vision.
The key to achieving this level of alignment among the critical stakeholders is that they know how to delegate decisions while being transparent about the underlying system. Moreover, they include everyone at a meaningful level in the subsequent communication and collaboration, respectively, using the “vision, validation, value” approach.
A less successful PO typically fails to have a product mindset and act as a team player. They fail at being product leaders. Instead, they are typically stuck in the scribe mode, refusing to delegate work that others can perfectly handle for them. For example, there is no reason why a PO would create and write all Product Backlog items themselves. In my experience, Developers can author PBi very well.
Also, they tend to shield the rest of the Scrum team from communicating with stakeholders, namely customers and users. Establishing these team-internal functional silos — Developers develop and do not talk to customers — often lowers innovation and productivity. Generally, they tend to create a bubble for themselves where falling victim to confirmation bias is not uncommon. They start loving their solution instead of the customers’ problem.
Additionally, less successful Product Owners also tend to invest less in creating a product mindset throughout the organization. For example, they rely less on joined work sessions with stakeholders like user story mapping, value stream mapping, or impact mapping. Also, they are less transparent about the status quo and where the Scrum team is heading.
Your new product proves to be very desirable in the market, and your organization—and hence the number of Scrum teams and stakeholders—is increasing rapidly in size. So, how do you preserve a product mindset as the responsible Product Owner?
Here, the candidate should point at the importance of embracing empiricism, self-management, and autonomy to deliver value to customers within the constraints of the organization while creating a sustainable return on investment for the latter:
In what ways can you support your personal growth as a Product Owner if your organization is still stuck in the old ways and far from developing a product mindset?
Even the longest journey starts with the first steps. If the “Product Owner” position is currently that of a glorified scribe taking requirements from stakeholders, and you aim to move to the entrepreneur level, I would at least explore the following steps:
How can you help other Scrum team members, namely the developers, develop a product mindset?
Speaking with John Doerr, you want missionaries, not mercenaries on your team. To achieve that state, I would recommend taking the following steps:
Please note that not all Developers feel comfortable with the idea of investing much time in communicating or collaboration with stakeholders while neglecting to build the product or service. (Some just like to solve puzzles all day long — which is okay as you cannot force people to get involved in these activities.)
So, embracing a “customer problem first” perspective, thus developing a product mindset throughout the organization, seems to be a good bet to create value for everyone. How would you engage with different groups of stakeholders in the process? How have you done so successfully in the past?
The question is designed to provide the Product Owner candidate with room to share their experience and shine. Also, it is about understanding whether they have a holistic approach to stakeholder communication and what drives a stakeholder to interact with a Scrum team. Interacting comes in many different forms, from exercising control to pursuing goals (probably also personal agendas) to being kept in the loop. The candidate should have explored some of the following approaches to stakeholder engagement:
Engaging with users:
Engaging with providers:
Engaging with governance people:
Engaging with influencers:
This latest update to the interview guide addresses product mindset; see questions 77 to 82.
This latest update to the interview guide addresses Product Owner anti-patterns from Product Backlog management and refinement to the Sprint Review; see questions 72 to 76.
How can we learn during the Product Owner interview whether a candidate has experience with facilitating remote agile events?
To figure out the candidate’s competence level, I like to run a Liberating Structures-based exercise during the interview. I use TRIZ to task the Product Owner candidate to come up with suggestions on how to sabotage a remote Scrum approach effectively when talking to teammates, internal stakeholders or customers. (Who is considering running user tests in person at the moment?)
These are some of the remote agile anti-patterns the candidate should be able to identify:
For a comprehensive list of anti-patterns, read Remote Agile (Part 4): Anti-Patterns — Pitfalls Successful Distributed Teams Avoid.
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.
Regarding certifications of candidates, I recommend looking out for those with PSPO I, PSPO II, and particularly PSPO III certificates from Scrum.org.
60 Scrum Master Interview Questions to Identify Suitable Candidates.
Product Owner Anti-Patterns — 31+2 Ways to Improve as a PO.
Peer Recruiting: How to Hire a Scrum Master in Agile Times
Download the ’Scrum Anti-Patterns Guide’ for Free
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.
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: 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…
TL; DR: Scrum Master Interview Questions on Creating Value with Scrum If you are looking…