Product Owner Interview Questions and Answers – Part II

Product Owner Interview Questions and Answers contains most frequently asked questions that you might face in interview & this will help you competently crack the interview. A Scrum Product Owner is responsible for maximizing the value of the product resulting from the work of the Development Team. How this is done may vary widely across organizations, Scrum Teams, and individuals. Product Owner Interview Questions and Answers will test your knowledge as a PO.

Product Owner Interview Questions and Answers – Part I: Click Here

Please read Agile Interview Questions and Answer for interview questions related to Agile Fundamentals. Scrum Interview Questions and Answer for interview questions related to Scrum Fundamentals.

Product Owner Interview Questions and Answers

Question: What have you done in the past 5 sprints, to increase the chances of delivering a high-value product?

Answer: Try to answer below mentioned questions from your experience, it will provide enough data to talk about delivering a high-value product.

• Do the Developers have access to stakeholders as needed?
• Does the PO engage with stakeholders frequently?
• Does the PO act as a matchmaker between the Developers and stakeholders rather than a bottleneck?
• How are the different needs of different stakeholders balanced?
• How does the PO track profit and loss?
• Does the PO ensure that user or stakeholder satisfaction is measured regularly?
• Does the PO keep a burn-up chart of “value points” delivered per Sprint, or is there some other way to guess or measure delivered value?

Question: What can you learn from a daily burndown chart that you can’t see on an iteration burndown chart?

Answer: Daily burndown charts show the progress of the team during the iteration. You can use this information to gauge whether all planned work will be completed by the end of the iteration. If it becomes apparent that not all work can be completed, the team and customer can talk during the iteration about which work should be deferred.

Question: What circumstances would cause an iteration burndown chart to reflect an upward trend?

Answer: An iteration burndown chart will trend upwards if new work is being added faster than known work is being completed, or if the team decides that a significant amount of future work has been underestimated.

Question: There are new features that need to be delivered in the next sprint. But the technical debts are in an increasing trend, in this situation, how will you handle them?

Answer: Both are important and one can’t be neglected for the other. The technical issues get in the way of delivering value; development slows while costs rise. The most critical aspect of managing technical debt is to regularly address the issues as part of your normal development workflow. So when I have to plan for valuable new features and technical debt in a product backlog, as a product owner, with every sprint, along with the features I will include a limited number but most important and the most pressing issues caused by technical debt. As a Scrum team, we can also allocate a certain percentage of resources to technical debt and the rest to critical prioritized features. 

Question: As a Product Owner how do you communicate marketplace knowledge and changes/demand to the Scrum Team?

Answer: Scrum team must be aware of the changes happening & new demands in the market place. The product owner provides a clear vision and sprint goals to the team to help them stay updated with the product. If there is any change in the backlog with respect to new requirements or priorities, it should be communicated to the teams. This will helps the team to understand the bigger picture & give a clear perspective on the product they are developing. It is one of the critical responsibilities of the product owner. The PO does it continuously as a part of his informal interactions with the development team and Scrum Master. He also does that through formal discussions and meetings.

Question: How do you manage changing requirements?

Answer: Here interviewer trying to test your management skills & Agile approaches to managing changes in requirements, such as:

• Implements / follows a process that allows for feedback and changes to flow through the PO. Customer input happens throughout the development process.
• Determines the scope of the change and the scope of incorporating the change
• Implements / follows a transparent change approval process to gain approval or rejection of the change. Daily meetings promote communication. Task boards make developer tasks and details visible.
• Use of the agile framework, Product backlog sets development priorities e.g. product backlogs and sprints to communicate and implement approved change requests and keeps change logs in a shared / visible platform.

Question: What is your approach to creating and managing product roadmaps?  

Answer: This is a tricky question, for a small organization the PO might be directly involved in creating the roadmap however in a large organization, he would be someone whose input would be required for creating a product roadmap. So focus should be on the vision or objective, as opposed to granular feature details.

• Plans to develop a road-map that is lightweight articulates and validates the product strategy—the path to deliver the vision
• Approaches to ensure stakeholder engagement and secure buy-in.
• Approaches to measuring the roadmap
• Plans to regularly review and adjust the roadmap

Question: What is the difference between Release PO and Feature PO?

Answer: When the backlog is too big to be taken care of by a single product owner, there is a need for adding a person who can take care of the bigger picture. Hence the role of a release product owner comes up. For example, the team product owner works with the development team for feature delivery and in turn, the release product owner will work to formalize the release of those features to the market. The feature product owner ensures the feature is well understood by the team and they also make sure, it gets delivered on time if there are no impediments. There can several features the team can be working on. The release product owner takes care at the higher level to consolidate the feature delivery through a release, they set the release dates, which can go from a month to six months time. The feature PO is more focused on the team and collaborates with the delivery teams whereas the Release product Owner interacts with the team of the product owners.

Question: What is technical debt with respect to a Product?

Answer: Technical debt is the difference between what was promised and what was actually delivered. Preventing technical debt is what allows development to be agile in the long run. Technical Debt is something where you are required to do refactoring or improvement related to the source code and its architecture. Factors adding up to technical debts cab be issues related to architecture, structure, duplication, test coverage, comments, and documentation, potential bugs, complexity, code smells, coding practices, and style. All these types of issues incur technical debt because they have a negative impact on productivity. Any compromise with the quality during the development lifecycle leads to technical debts, the software becomes fragile and expensive to extend and maintain. With the evolution of agile, we have witnessed a gradual decrease in the amount of technical debt and this was feasible because now we follow shorter cycles and frequent software updates require high quality, hence, the chances of piled-up issues are lower.

Question: What is a Release Burndown Chart and how scrum team uses this chart?

Answer: A Release Burndown Chart is a tool for monitoring team performance and project progress. There are several chart types: sprint burndown chart, release burndown chart, and product burndown chart.  It is one of the information radiators for an agile project team and is a way for the team to clearly see what is happening and how progress is being made during each sprint.

A release burndown chart provides an overview of the release progress by plotting the remaining workload, often referred to as the remaining effort in Scrum, at the end of every sprint against the ideal workload (or effort). The release burndown chart has sprints or timelines on the X-axis and the story points on the Y-axis. It captures how much scope has been increased during the course of a release, it also gives us insight into the stories getting acceptance on time from the PO or the stakeholders.  With the help of this chart, we can even identify if there are any risks to the delivery in the said amount of time.

Question: How to maximize the value of the Development Team’s work?

Answer: The Product owner can very well increase the value the team delivers. Continuous interaction is one of the factors that contribute to maximum value being delivered. Other factors can be –

• Domain Training – Investing time in teaching the development team about the domain, helping them understand the business and how it works.
• Vision – Take out time to explain the vision for the product and the organization.
• Value Delivery – Making the team understand the value being delivered at the story level. How the story can impact the overall product? How can the team deliver the highest value item? As a product owner, you should have these discussions with the team.

This not only encourages the team and helps them own the product but it also helps the overall business.

Question: During the review, suppose the product owner or stakeholder does not agree with the feature you implemented what would you do?

Answer: It is not always possible that the product owner agrees to what the team has developed. If the team has delivered the story/feature as per the acceptance criteria mentioned and has covered all the scenarios around that feature, then we can ask the product owner to accept the story/feature and anything which is not covered will be taken up in the new feature or a new story. But in the case where the product owner is not agreeing to the feature you delivered and it was part of the acceptance criteria then the product owner has all the rights to not accept the item. In this case, the team can take this up as the retrospective point as to where they missed, and how it got shaped in a different way. The team should introspect what went well and how can they make it better. They should again set up a meeting with the product owner to get a clear understanding of the requirements so that they do not deviate from what is expected.

Question: What are the desirable qualities of the vision?

Answer: The vision forms the foundation of any product, it is something that encourages and inspires people to stay on the right path, hence it should be clear and firm; extensive, and appealing. Vison should be Imaginable, Desirable/Compelling, Achievable/Feasible, Challenging, Aligned/Focused, Flexible & Communicable. To list out a few desired qualities of the vision, let’s look at the following points:

Clear and firm – A good product vision should be easy to grasp and interpret and creates a common purpose for the teams while avoiding confusion and misinterpretation. Visions may change with changing factors. Small adjustments are allowed provided the value proposition of the item is retained. But big adjustments may cause confusion, project failure, and demotivation.

Extensive and appealing – It should provide a very high-level view of where we want to go, and also provides the development team with space to come up with ideas, collaborate, find solutions, to inspire to achieve more. It should encourage the team for better delivery in line with customer expectations.

Brief and concise –It should contain only information critical to the realization of the product. It is not a list of requirements, hence, it should not cover the minute details. In simple terms, it should be short and sweet.

47. How are vision and goals aligned to the product backlog?

Answer: The product can only deliver value if it is aligned with the vision and goals. The Product vision defines the purpose of a Product, the intent with which the Product is being developed, and what it aims to achieve for customers and users. When the product owner discusses the backlog with the development team, they refer to the order in the backlog which is based on the value. Vision provides a high-level view of what the future product should look like, it helps the development teams shape the product in a way it meets the required goals, as set by the customer. The product owner helps the team in identifying the sprint goals which are in line with the product vision so that the teams can deliver maximum value to the customer. The vision and goals are even linked to the MVPs (Minimum Viable Product). In Agile, the vision statement becomes a guiding light, the “what we are trying to achieve” statement that the development team, scrum master, and stakeholders refer to throughout the project.

Question: If you were given two products to build from scratch, but only had the time and resources to build one, how would you decide which to build?

Answer: This is a Product Manager role as PO is associated with only one product. Product strategy means saying no from time to time. The product manager should prioritize by cherry-picking the project that’s likely to generate 80% of the impact and forecast what that impact is, as well as the cost in resources, money, and other scarce resources before they decide to build.

This framework forces a product manager to really think through themes, create a plan, allocate resources, eliminate the need to prioritize different projects against each other, and model/forecast the impact.

Question: Explain in Agile why planning is adaptive, iterative, and collaborative?

Answer: Planning is adaptive, iterative, and collaborative which means, planning takes place at different levels in Scrum:

Product, release, sprint, and day. Each level has some output which gets as an input for the next level. When we talk of planning in Scrum, it is more dynamic and changes as more information about the customer’s need and the product being developed become available. The product gets built over every iteration, at the end of every sprint, there is an increment that gets added to the product. The team plans for each iteration in a release with the collaboration of the product owner and the stakeholders. The release planning activities are carried out by the Scrum team often with the help of stakeholders, for instance, in the sprint review meeting, the team presents the backlog they have worked upon and takes the acceptance from the product owner. If there is any feedback on the items, they will be added to the product backlog and later would be prioritized by the product owner. The product owner ensures that the necessary release management activities take place. It is more of a collaboration among the product owner and the teams which results in the success of the product.

Product Owner Interview Questions and Answers – Part I: Click Here

Disclaimer: All the content related to Scrum Guide is taken from scrumguides.org and is under the Attribution ShareAlike license of Creative Commons. Further information is accessible at https://creativecommons.org/licenses/by-sa/4.0/legalcode and also described in summary form at http://creativecommons.org/licenses/by-sa/4.0/.