Professional Scrum Product Owner II (PSPO II) Interview Questions

The Professional Scrum Product OwnerTM level II (PSPO II) assessment is available to anyone who wishes to validate their advanced knowledge of Professional Scrum Product Ownership, the Scrum framework, and delivering valuable products. Those who pass the exam will be awarded the industry-recognized PSPO II Certification, which shows that they have mastered the material.

Course Outline

• Understanding and Applying the Scrum Framework
• Managing Products with Agility
• Evolving the Agile Organization

1.) In the first place, what is the point of being agile?

It is mostly about adaptability over following a plan, as stated in the “Manifesto for Agile Software Development.” To paraphrase Peter Drucker, it is more about doing the right things than it is about doing the right things. When it comes to product development, being agile means deferring investment decisions until the most economically possible time. This is accomplished by testing hypotheses as quickly and cheaply as feasible, hence reducing risk and maximizing the development team’s productivity. It also entails having the fortitude to call a halt to an activity if the selected path is no longer viable.

2.) Is the Product Owner a “product manager” to some extent?

The distinction between a product manager and a Product Owner is blurry, and it all depends on how the function is defined in the organization’s structure and culture. Product Ownership typically comprises defining the product vision and strategy, aligning it with the company’s goals and objectives, and managing any internal and external stakeholders involved in the process, in addition to product management responsibilities.

3.) How do you work with the other members of the Scrum Team?

Early, often, respectfully, transparently, being available on a regular basis, and reacting quickly and attentively. “The Scrum Team is responsible for all product-related tasks, including stakeholder cooperation, verification, maintenance, operation, experimentation, research and development, and anything else that may be required,” according to the Scrum Guide 2020.

4.) What Scrum events is the Product Owner expected to participate in?

Daily Scrums, Sprint Planning, Sprint Review, and Sprint Retrospectives are all events in which the Product Owner is expected to participate. Otherwise, the Product Owner will be unable to respond to potential queries promptly, and barriers will not be resolved in a timely manner, which is in direct opposition to the agile ethos.

5.) How much time do you spend on user research and figuring out what your customers want?

It would be fantastic if they could spend half of their time with customers. If it’s less than 10% and no one else is managing product discovery on the Product Owner’s behalf, the product discovery process should be enhanced. By relieving the PO of administrative responsibilities such as authoring user stories, for example.

6.) What exactly is the Scrum framework?

Scrum is a time-boxed iterative and incremental approach to delivering value to consumers. It’s a straightforward structure for facilitating effective team communication on big projects. At OOPSLA’95, Jeff Sutherland and Ken Schwaber invented Scrum as a formal procedure. Scrum is a relatively simple and easy-to-understand methodology for any team, yet it is quite challenging to master.

The values of scrum are Courage, Focus, Commitment, Respect, and Openness, and any team embracing scrum should be open to adopting these characteristics in order for the team to succeed. As previously said, scrum is very light and does not prescribe much in the way of hierarchy or embedded roles; instead, it just mentions three (3) basic roles: Product Owner, Scrum Master, and Scrum Team. Scrum Teams are cross-functional and self-organizing. Rather than being guided by individuals outside the team, self-organizing teams choose the best way to accomplish their goals. Cross-functional teams have all of the necessary competencies to complete the task without relying on those who are not members of the team. According to a survey conducted by Version 1, scrum is the most extensively utilized framework worldwide.

7.) What distinguishes User Stories from traditional requirements?

Let’s first define a user story before moving on to the standard criteria. If you work in an agile organization these days, you’ll hear everyone talking about user stories.

User stories are brief descriptions of functionality told from the perspective of the user, with the emphasis on why and how. The user story focuses on the user’s experience, or what they want to be able to do with the product. A traditional requirement focuses on functionality, or what the product should be able to perform; it speaks more in terms of a product’s capacity. Traditional requirement documents go into great detail about how a particular piece of software should be built.

8.) What is the location of the customer requirements?

A Product Backlog stores all of the requirements derived from a customer’s needs. When a request is received, it is first added to the product backlog, where the business owner or product owner can prioritize the items based on market and consumer demand. It’s similar to a bucket in that it collects all of the necessary components for delivering a finished product. A product backlog can be created in a variety of ways: some people use manual charts, some use excel, and still, others utilize Agile-supporting technologies like Rally, Version 1, and so on. Always keep in mind that the product backlog is not a replacement for a requirements definition. Any customer feedback received during the demo or grooming call should be recorded and added to the product backlog. This ensures that nothing is overlooked, even if it is a low-priority topic.

9.) What does a definition of Ready entail, and what are the elements that make it up?

The product backlog contains a wide range of items such as new requirements, additions, bug fixes, refactoring stories, and so on, but it’s critical to ensure that the items are in a state that allows a team to commit to them. To elaborate, the items that the team commits to in a sprint must match a set of criteria to ensure that they have all they need to work on them.

Ready is defined as an agreement between the team and the product owner that backlog items must pass through a few agreed-upon milestones before being marked as ready. For example, User Story developed, User Story dependencies recognized, User Story sized by the delivery team, performance criteria determined, no outstanding questions and the team has a good concept of what it will mean to Demo the User Story.

10.) What is the Burndown Chart for a Release?

A Release Burndown Chart is one of the information radiators for an agile project team, allowing everyone to understand what’s going on and how far they’ve come in each sprint. Sprints or timelines are on the X-axis, while story points are on the Y-axis, in the release burndown chart. You can determine how the release is progressing just by looking at the chart. It tracks how much scope has been expanded during the course of a release, as well as provides insight into which stories have received timely approval from the PO or stakeholders. We may also use this chart to see if there are any hazards to the delivery occurring within the specified time frame. It is primarily used by the product team, management, and occasionally stakeholders to evaluate the release’s delivery. When we engage with business owners, this is an important graphic since it shows items that may stray outside of the restrictions.

11.) When it comes to estimating and committing, what’s the difference?

• When an agile team works on a product backlog, they break it down into chunks and align them into a delivery plan. They also estimate the product backlog during this process, which gives them visibility into its completion, functional approach, and complexity. Estimates provide a high-level picture of how long it will take to deliver the item. Commitment, on the other hand, is a team’s assurance that things taken in a sprint or release will be delivered.
• During the sprint planning meeting, the team pulls in some things based on collective capacity and commits to delivering them in a time-boxed way to the product owner or stakeholders.
• Estimating and committing are both vital scrum actions, but they serve very distinct goals. The team never makes a commitment based on estimates. An estimate is our best guess at what can be accomplished and when it can be accomplished. Always remember that committing does not guarantee that items will be delivered; there may be instances where the team becomes stuck due to a valid and acceptable hindrance. A team can estimate the backlog in a variety of methods.

12.) Define the term “technical debt.”

Ward Cunningham created the phrase technical debt to describe how some code issues are similar to financial debt. “You can achieve something sooner with borrowed money than you might otherwise,” Ward says, “but you will pay interest until you pay back that money.” Technical debt occurs when you are obliged to perform refactoring or improvements to the source code and architecture.

Issues with architecture, structure, duplication, test coverage, comments, documentation, possible flaws, complexity, code smell, coding habits, and style can all contribute to technical debts. Because they have a detrimental influence on production, all of these concerns result in technical debt. Any sacrifice of quality during the development lifecycle results in technical debts, making the software vulnerable and costly to extend and maintain. Because we now follow shorter cycles and frequent software upgrades need good quality, we have seen a gradual decline in the amount of technical debt, which was possible because the odds of piled-up issues have decreased.

13.) Why do we advocate for early and frequent software releases?

Early and frequent deliveries benefit both the staff and the clients. When we begin working in iterations, an increment is introduced to the product; this increment is always (in most situations) the top priority item, as customers demand. As a result, every time the customer receives the completed task that they have been pursuing as critical or highly needed.

Customers benefit from short iterations because they have more time to adjust priorities and align requirements with market needs. On the other hand, while working on software development in short cycles, the team receives positive feedback early on. They receive feedback as soon as they deliver completed things to their clients. During the demo, clients may be able to see what has resulted from their needs; as a result, they may adjust and provide feedback, which is then translated into a story and taken up by the teams. When compared to delivering anything large, early and frequent releases ensure that the scope of change is limited. Every iteration (release) includes a specification, development, and testing process. This means that the software is fully useable every couple of weeks, even if it just has a few capabilities at first.

14.) Define the role of the Product Owner.

A product owner is a member of a product development team or a Scrum team who is in charge of the product backlog, ensuring that it is current in terms of priority and contains items that are aligned with the company’s vision. The Product Owner is responsible for collaborating with the customer to determine which features will be included in the product release.

The Product Owner collaborates with stakeholders to develop the proper needs, which means assisting users in developing requirements that they may not be aware of or comprehend at the time. This not only enhances our consumer relationships, but it also helps to establish trust. The Product Owner, on the other hand, assists the delivery team/development team in comprehending the vision and needs. As a result, this position acts as a link between the two ends, binding the two corners together and facilitating easy communication. This function is extremely important since it acts as a bridge between the development team and the stakeholders.

15.) Who are the people in charge of the POs?

Everyone participating in the product holds the Product Owners accountable. They are responsible to their clients for delivering high-quality products, and they must ensure that needs are accurately translated and that the deliverables are understood by all parties. Clients look on product owners for their requested work and for feedback loops to be taken care of. Similarly, product owners are responsible to the delivery team for ensuring that they receive the proper set of criteria to begin their work.

They are also in charge of the milestones and the roadmap, ensuring that everyone is on the same page. They are even answerable to the management because they are in charge of the funds. The product owner is even responsible for the health of their product backlog! A lot goes into the product owner’s accountability; it’s almost like they’ve conducted 360-degree accountability. The product owner is responsible for whatever work the development team undertakes, including ensuring that the team develops the correct product.

16.) What is the difference between a Release PO and a Feature PO?

• When the backlog grows too large for a single product owner to handle, it’s time to bring in someone who can look at the larger picture. As a result, the role of release product owner emerges. The team product owner, for example, collaborates with the development team to create features, while the release product owner works to formalise the release of those features to the market.
• If there are no obstructions, the feature product owner ensures that the feature is fully understood by the team and that it is delivered on time. The team may be working on a variety of features.
• Please describe the governance of your product line.
• The answer will differ slightly from one contender to the next. If he works in a large organisation with several teams working on the same product lines, he will discuss his peers and coordination, the product line hierarchy (such as Product Owner, Area PO, Product Manager, Chief PM), and, in the event of a distributed agile team, Proxy PO at off shore. If he comes from a small company, he’ll tell about meeting and coordinating with business executives and salespeople.

17.) You’ve prioritised critical new features for the following sprint. How will you deal with fresh defects and increasing technical debts in that case?

When valuable new features compete with bugs and technical debt in a product backlog, as a product owner, I will include a restricted number of the most significant problems and the most pressing issues caused by technical debt in each sprint, along with the features. We can also set some basic thumb rules for it, such as assigning 10% of resources to bugs, 15% to technical debt, and the rest to new features, depending on the product.

18.) What would a Product Owner do if a stakeholder refused to cooperate?

The best (and possibly only) method to deal with resistant stakeholders is to gain their trust through regular meetings and talks, as well as by proving the value of agile product development. If ID fails, the product owner should seek assistance from the sponsor.

19.) How do you intend to launch your product? Is it true for every sprint?

No, every sprint does not have to be released. The release is a business and strategic activity, whereas deployment is a planning activity that can be done each sprint or continuously. Although the development team may continue to work on a shippable product, the choice to ship is a business one. When it makes sense from a business standpoint, the PO or product manager will schedule a release date.

20.) What is the definition of systems thinking? How vital is a Systems Thinking approach for a Product Owner?

The term “systems thinking” refers to a holistic approach to problem-solving. It provides a whole picture. It is critical for a Product Owner to have a thorough picture of the product; only then will he be able to build a product vision. A holistic view will also help him comprehend why the Product roadmap has changed and why he should alter the product backlog items if he works in an environment with a complete product management line of product managers above him.

21.) What changes will you make if you become the product owner of Gmail?

The response to this question will reveal the candidate’s product owner. It’s possible that various candidates will respond in different ways. Some may discuss the new look and feel features or UX (User Experience), while others may discuss how Gmail as a product will evolve, such as its integration with other existing products, or vice versa, such as G-Pay integrated with Gmail or making it a one-stop-shop for all your needs – communication, collaboration, banking, and shopping, for example. This demonstrates the person’s point of view.

22.) Do we need a Product Owner for a DevOps team now that DevOps is the new industry buzzword?

Yes. A product is also the focus of a DevOps team. With CI/CD and automation, it’s more vital than ever for the DevOps team to understand business requirements and needs before automating the delivery process. Without a Product Owner, the business need could not be understood correctly, and doubts could not be answered.

23.) What characteristics do sprints have?

The sprint, like any other entity, has a few properties:

• Timeboxing — Almost everything in a sprint is timed, including the ceremony and the race itself. Timeboxing creates a disciplined environment with defined bounds for any scheduled task. It aids the team’s focus; remember back in the day when the actual study began the day the exam dates were announced?
• Following a fixed time box in development establishes a cadence and aids in the collection of metrics at regular intervals. For example, we calculate the team’s velocity every time box (Sprint).

• Protected from any changes – Scrum states that the sprint scope will be locked once the team has made a commitment in the Sprint Planning. Any modifications to the commitment in terms of scope are discouraged. The team should pull it up if the change is modest enough to be implemented in a sprint, as the Agile Manifesto also mentions ‘Responding to Change above Following a Plan.’
• A sprint should last no more than one calendar month.

24.) What variables influence the order in which a product’s backlog is prioritised?

When it comes to prioritizing the product backlog, there may be several reasons that obstruct the process. To name a few, the first is the time required for completion; even though the item is a high priority, development requires time to accomplish it, and this does not fit into a sprint. In this instance, the product owner must first grill out the most important component of the demand.

Then we’ll be able to have, Relationship between urgently essential tasks and other duties that are correlative or conditional. It’s possible that the urgently required jobs and other tasks in the pipeline are intertwined.

25.) Why is it argued that quality is frozen?

In agile, we talk about quality at all phases, whereas in a waterfall, quality was prioritized at the beginning of the SDLC rather than later. We make sure that with Agile, there are checkpoints in place to ensure that whatever is sent out meets the quality level. As a result, we establish the definition of done, as well as the quality requirements.

This definition of done is agreed upon by the team and the stakeholders, and it is set for a sprint (at the minimum). Only once the stories committed by the team have met the requirements given in the definition of done can they be marked as complete. The team can define unit testing, code review, coverage, and other parameters in the definition of done, and if the team is working on accessibility, they can include compliance criteria. As a result, quality is fixed at the beginning so that whatever demand is shipped adheres to the established standards. Similarly, with the support of a definition of ready, we may have a quality backlog to enter into sprints.

26.) What role does a release strategy have in forecasting the future?

We can forecast how much the teams can provide in the forthcoming sprints if we get the data points from their historical velocity. In a release plan, we talk about the sprints for the next three to six weeks (or whatever the release timeline is). With the use of historical data, the sprint may be aligned with the figures, and the team’s effort can be totaled.

If the team’s average velocity is 30, we may estimate that in the following release, which comprises six sprints, the team will be able to do 180 points worth of work. We can even predict ahead of time what dependencies will arise throughout the development period thanks to releasing planning. The release plan varies for each organization, but it is an important component of iteration planning.

27.) When is it acceptable to call off a sprint?

The most common reason for cancelling a sprint is a significant shift in priorities, which indicates that something that was previously considered vital has dropped down the priority list and something with a critical priority has risen. If needs that were previously considered high priority are now tagged as low priority, the committed items in a sprint will be effected automatically.

As a result, there’s no use in continuing. It is not a good practice to cancel sprints frequently since it shows that the stakeholders or product owners do not have a clear understanding of what they are looking for. They are unable to prioritize the backlog and may require assistance. It is a common misperception that the sprint may only be canceled by the product owner. This is incorrect. The product owner has the authority to cancel the sprint, but other criteria must be considered as well. After the sprint has been cancelled, the team’s first task will be to plan for the next sprint.

28.) Does a Product Owner have a say in when user stories are released?

Because the product owner is the client’s or customer’s face in the scrum, the individual who plays the role will have power over the product being built. The product owner decides what will be included in the release and when it will be released. The product owner does, in fact, have veto power over the release of user stories. This is true for any and all business requirements or flaws that are being delivered. The only thing the product owner has no control over is the technical debt. The developer is the one who takes responsibility for the product and publishes it. The product owner sets the release dates and releases candidates well in advance so that the teams have enough time to develop and deliver. If the user stories do not fulfill the expectations, the product owner can accept or reject them.

29.) What are some of the obstacles of being a Product Owner?

The Product Owner, like everyone else in an agile team, faces a number of obstacles; here are a few of them:

Product Owners should design a product roadmap based on research, business standards, and best practices rather than building product feature only on the basis of a client’s customization requirements.

High-level acceptance criteria

You should use the INVEST model to build the framework with the Product Owners. If the story is overly thorough, the team will believe that their questions have been answered and that there is no room for debate.
Investing too much effort in product support rather than trimming the backlog

Changing priorities in the middle of a sprint

Working around the product roadmap, focusing on high-value backlog items, creating crisp acceptance criteria, focussing on grooming quality backlog items, and avoiding disruptive sprints are all ways for Product Owners to avoid these common traps.

30.) How do you deal with “Distant Product Owners”?

“An out-of-town product owner operates independently from the team. However, distance comes in a variety of shapes and sizes. It begins with different rooms working on the same site and culminates with the product owner and team being divided across continents and time zones. I’ve noticed a pattern of mistrust, miscommunication, misalignment, and poor progress with faraway product owners.” – Pichler, Roman

To avoid any gaps in the information being processed, the team must be in continual communication with a remote product owner. At the very least, remote product owners should be present at the sprint planning, review, and retrospective sessions. They should use video conferencing on a regular basis to assist with face-to-face encounters; this not only instills confidence but also aids in the delivery of the correct product. Because any lag would cost them time in a sprint, teams with ‘Distant Product Owners’ should respond to their concerns as soon as they receive them. It is usually preferable to go from a remote to a co-located product owner because they are present at all times to answer questions and assist the teams in achieving their objectives.