Scrum PSPO-II Professional Scrum Product Owner™ II (PSPO II) Exam Practice Test

Frequent product releases are beneficial for several reasons. They enable teams to inspect and adapt more frequently, which means they can get faster feedback, validate their assumptions, and improve their product incrementally. They help teams better understand and meet customer needs, which means they can deliver more value, increase customer satisfaction, and build trust and loyalty. They help teams to learn how to correct and eliminate errors, which means they can reduce waste, improve quality, and prevent technical debt. Smaller, more frequent releases are less risky, which means they can reduce uncertainty, avoid big-bang failures, and enable faster recovery123. References: 1: Managing Products with Agility 2: Understanding and Applying the Scrum Framework 3: Evolving the Agile Organization

The Product Owner is accountable for maintaining and communicating the Product Goal. This responsibility includes ensuring that the goal is visible to everyone and provides direction and purpose for the Scrum Team and its stakeholders

According to the PSPO II guide and Scrum.org competencies, when ordering Product Backlog items, a Product Owner should consider various factors to maximize the value of the work done by the Scrum Team. These factors include:

• A. Dependencies to other products: Recognizing dependencies to other products is crucial for the Product Owner to ensure that the Scrum Team is working on items that can be completed and deliver value without being blocked by external dependencies.
• B. Value of Product Backlog items: The primary role of a Product Owner is to maximize the value delivered by the Scrum Team, and ordering items based on their value is a fundamental aspect of this responsibility.
• C. Dependencies between Product Backlog items: Understanding and managing dependencies between Product Backlog items helps in planning Sprints more effectively, ensuring that the team is working on items in a logical sequence.
• D. Cost of delay: The cost of delay is a critical economic factor that influences the ordering of Product Backlog items. Items that would result in a higher cost if delayed should be prioritized.
• E. Cost of implementation: While value maximization is the goal, the cost of implementation cannot be ignored. Balancing the cost and the expected value is essential for effective Product Backlog management.

These considerations are in line with the Scrum.org Professional Scrum competencies, particularly under 'Managing Products with Agility', where it's emphasized that Product Owners should have a deep understanding of market value, product feasibility, and the importance of making trade-offs to maximize value.

 According to the Professional Scrum Product Owner™ II certification guide1, the Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team. This means that the Product Owner should have a clear vision of the product, understand the needs and desires of the customers and stakeholders, and prioritize the Product Backlog items based on their value and urgency. The Product Owner should also use evidence-based management to measure the value delivered by the product and make informed decisions about the product strategy and direction.

In this question, Product A has a high current value, which means that it is generating a lot of revenue and satisfying the existing customers. However, it also has a low unrealized value, which means that it has little room for improvement or innovation, and may face competition or obsolescence in the future. Product B has a low current value, which means that it is not generating much revenue or satisfying many customers. However, it also has a high unrealized value, which means that it has a lot of potential for improvement or innovation, and may capture new markets or opportunities in the future.

Taking a long-term view, the Product Owner should weight the investment toward Product B, since it has more potential to deliver value in the future. This does not mean that the Product Owner should neglect Product A, but rather balance the investment between the two products based on the expected return on investment and the risk involved. Investing equally in both products may not be optimal, as it may result in underinvesting in Product B and overinvesting in Product A. Weighting the investment toward Product A may not be wise, as it may result in missing out on the opportunities offered by Product B and losing the competitive edge in the market.

References: 1: Professional Scrum Product Owner™ II Certification | Scrum.org

A is correct because forming products that are as independent as possible reduces the complexity and dependency of the product development, and allows each product to deliver value faster and more frequently1. Coordination among the products is still necessary to ensure alignment and consistency, but it should not be centralized or imposed by a higher authority2. B is incorrect because creating a centralized, coordinated cross-product Development Plan goes against the principles of empiricism, self-organization, and agility that Scrum promotes3. C is incorrect because appointing a Project Lead to oversee all the products undermines the accountability and autonomy of the Product Owners and the Scrum Teams4. D is incorrect because ensuring that the PMO manages the inter-product dependencies creates a layer of bureaucracy and control that hinders the collaboration and innovation of the Scrum Teams5. E is incorrect because it includes all the wrong answers.

 The Product Owner is the sole person accountable for managing the Product Backlog and ensuring the value of the work the Scrum Team performs. The Product Owner is one person, not a committee. The Product Owner may represent the desires of a committee in the Product Backlog, but those wanting to change a Product Backlog item’s priority must address the Product Owner1. The Product Owner is responsible for the product and its outcome2.

A product is a vehicle to deliver value. It has a clear boundary, known stakeholders, well-defined users or customers. A product could be a physical product, a software product, a service, a project, or something else3. A product has a product vision, which is the overarching goal of the product, the reason for creating it, and the impact it should have on its customers and users4.

A portfolio is a collection of products or projects that are aligned with a strategic goal or an organizational unit5. A program is a group of related projects or products that are managed in a coordinated way to obtain benefits and control not available from managing them individually. A portfolio or a program may have a portfolio or program manager, who is responsible for overseeing the alignment, prioritization, and governance of the portfolio or program . However, these roles are not equivalent to the Product Owner role, as they do not have the same accountabilities and authorities as the Product Owner.

Therefore, the correct answer is that a Product Owner is needed for every product, not for every portfolio or program. References: 1: Scrum Guide 2: Understanding and Applying the Scrum Framework 3: Managing Products with Agility 4: [Product Vision] 5: [Portfolio] : [Program] : [Portfolio Management] : [Program Management]

Verified Answer: C

Very Very Short Explanation: According to the PSPO II guidelines, the focus should be on improving time-to-market and rate of innovation to enhance responsiveness ©. This aligns with the principles of agility and Scrum, which emphasize the importance of delivering value quickly and responding to market changes123. By improving these areas, you can better meet customer needs and compete more effectively in the market.

 The smallest product Increment that is valuable enough to release is one that delivers a single new or improved outcome for the customers or users of the product. This is because the outcome is the ultimate measure of value, not the output or the features1. An outcome is a change in behavior, attitude, or situation that results from using the product2. An outcome can be achieved by delivering a single feature, fixing a defect, or improving an existing functionality, as long as it meets the Definition of Done and the Sprint Goal3. Therefore, the best answer is A.

The other options are not correct because:

• B. Adds a new feature. This is not a sufficient condition, as a new feature may not deliver a valuable outcome if it is not aligned with the product vision, the customer needs, or the market conditions4.
• C. Fixes at least one defect. This is not a necessary condition, as a defect may not affect the value of the product if it is minor, rare, or irrelevant to the customer5.
• D. Delivers all “must do” Product Backlog items. This is not a realistic condition, as the Product Backlog is a dynamic and emergent artifact that changes based on feedback, learning, and discovery. There is no fixed set of “must do” items that can guarantee the delivery of value. References: 1: Outcome vs. Output, 2: What is an Outcome?, 3: The Definition of Done, 4: Feature vs. Outcome, 5: Defect vs. Value, : The Product Backlog

According to the Professional Scrum Product Owner™ II certification guide1, a Product Backlog is an ordered list of what is needed to improve the product. It is the single source of work undertaken by the Scrum Team. The Product Backlog is owned by the Product Owner, who is accountable for maximizing the value of the product resulting from the work of the Scrum Team. Therefore, a separate Product Backlog is needed for every product, not for every Scrum Team, portfolio, program, or all of the above. Multiple Scrum Teams can work on the same product and share the same Product Backlog2. A portfolio or a program may consist of multiple products, each with its own Product Backlog3. References: 1: Professional Scrum Product Owner™ II Certification | Scrum.org 2: What is a Product Backlog? | Scrum.org 3: Product Backlog Explained [+ Examples] | Atlassian

The Product Backlog is an ordered list of what is needed to improve the product, and it is the single source of work undertaken by the Scrum Team. The Product Owner is responsible for ordering the Product Backlog items by value, risk, priority, and dependencies. The Product Backlog should be transparent and accessible to the Scrum Team and the stakeholders, so that everyone can understand the scope and progress of the product development. Therefore, options A and B are true statements about the Product Backlog.

Option C is not true because the Product Backlog items can be expressed in various formats, such as user stories, use cases, scenarios, or any other way that clearly conveys the intent and value of the item. User stories are a common and useful technique, but not a mandatory one.

Option D is not true because the Product Backlog is not a fixed and complete specification of the product, but rather an emergent and dynamic artifact that evolves over time. The Product Backlog items are refined and clarified by the Product Owner and the Developers throughout the product development process, and new items can be added or removed as needed. The Product Backlog does not need to be fully defined before the first Sprint begins, but only enough to support the first Sprint Planning.

Option E is not true because the Product Owner is not the only source of ideas and requirements for the product. The Product Owner collaborates with the Developers and the stakeholders to discover, validate, and prioritize the Product Backlog items. The Product Owner may delegate the authority to add items to the Product Backlog to others, but remains accountable for the ordering and the value of the Product Backlog.

Option F is not true because the Product Backlog does not replace the communication and collaboration between the Developers and the stakeholders. The Product Backlog represents the input of all stakeholders, but it is not a substitute for direct feedback and interaction. The Developers need to engage with the stakeholders to understand their needs, expectations, and feedback, and to deliver a valuable product increment that meets the Sprint Goal and the Definition of Done. References:

• Professional Scrum Product Owner II Assessment
• Understanding and Applying the Scrum Framework
• Managing Products with Agility
• [What is a Product Backlog?]
• [Product Backlog Explained]

• Self-Management: The Developers have autonomy over how they achieve the Sprint Goal. The Sprint Backlog reflects their plan for turning Product Backlog items into a valuable Increment.
• Accountability: The Developers are held accountable for delivering the Sprint Goal, and thus own the detailed plan within the Sprint Backlog.
• Scrum Guide: The Scrum Guide explicitly states, "The Sprint Backlog is a plan by and for the Developers"

• A. Importance to users or customers: The value an item brings to the customer is a key factor in ordering the Product Backlog1.
• B. Alignment with organizational strategy and goals: The Product Owner should consider how well an item aligns with the organization’s strategy and goals1.
• C. Risk: Business, market, and technology risks are important considerations when ordering the Product Backlog1.
• D. Alignment with other Product Backlog items: Dependencies and impact on other items in the Product Backlog should be considered1.

• Option A is correct because talking to users is one of the best ways to understand their needs, goals, and pain points. By spending more time with them, you can identify the impact they seek from your product and how your features align with that impact. This will help you validate your assumptions and learn from your customers12.
• Option B is incorrect because disabling features that have never been used is a risky and potentially harmful action. It may cause frustration and confusion for the users who rely on those features, or who may want to use them in the future. It may also damage your reputation and trust with your customers. Instead of disabling features, you should seek feedback from your users and understand why they are not using them34.
• Option C is correct because running experiments is a powerful way to increase your understanding of what customers find valuable. By testing different hypotheses and measuring the outcomes, you can learn from your data and evidence. You can also use experiments to validate your ideas and assumptions before investing in building features5 .
• Option D is correct because examining whether the rarely used features solve the intended problem is a crucial step to evaluate your product performance. You should review your product vision and goals, and assess how your features contribute to them. You should also analyze the feedback and data you have collected from your users and stakeholders, and identify any gaps or mismatches between your features and their needs .

References:

• 1: Product Backlog Management
• 2: Stakeholders & Customers
• 3: Product Value
• 4: Evidence-Based Management
• 5: Product Vision
• : Forecasting & Release Planning
• : [Business Strategy](https://www

 In Scrum, there is no separate artifact called a project plan. The Product Backlog is the plan for the product development, and it contains all the features, requirements, enhancements, and fixes that are needed to deliver a valuable product. The Product Backlog is not a static or fixed document, but rather an emergent and dynamic one. It is constantly updated and refined by the Product Owner and the Developers as they learn more about the product, the users, the market, and the technology. The Product Backlog is updated whenever new information and insights emerge, which can happen at any time during the product development process. Therefore, option C is the best answer.

Option A is not correct because the Daily Scrum is not a status meeting, but rather a time-boxed event for the Developers to inspect their progress towards the Sprint Goal and adapt their Sprint Backlog accordingly. The Product Owner does not need to update the Product Backlog after the Daily Scrum, unless there is a significant change in the product vision, strategy, or value proposition that affects the Product Backlog items.

Option B is not correct because the Sprint Retrospective is not a time to update the Product Backlog, but rather a time-boxed event for the Scrum Team to inspect their way of working and identify potential improvements. The Product Owner does not need to update the Product Backlog before the Sprint Retrospective, unless there is a need to communicate a change in the Product Goal or the product roadmap that affects the Product Backlog items.

Option D is not correct because the Sprint Planning is not a time to know how much work will have to be done in the Sprint, but rather a time-boxed event for the Scrum Team to collaborate on selecting and planning the Product Backlog items that will deliver the Sprint Goal. The Product Owner does not need to update the Product Backlog before the Sprint Planning, unless there is a need to reorder or clarify the Product Backlog items that are the most valuable and relevant for the upcoming Sprint. References:

• Professional Scrum Product Owner II Assessment
• Understanding and Applying the Scrum Framework
• Managing Products with Agility
• What is a Product Backlog?
• Product Backlog Explained

A sprint forecast is an estimate of what can be achieved in an upcoming Sprint. During Sprint planning, the team reviews the Product Backlog and selects stories that can be completed in the next Sprint based on the team’s velocity and capacity. The forecast is a pragmatic commitment to a realistic amount of work1. The forecast helps the team plan their tasks, prioritize their goals, and set realistic expectations for what they can accomplish during the Sprint. It also helps them to identify any potential risks or issues that could arise during the course of the Sprint2. The forecast is not a guarantee or a promise, but rather a best guess based on the current information and assumptions3. The forecast can be updated during the Sprint as new information emerges or as the team learns from their work4. The forecast is a useful tool for the Product Owner to communicate with the stakeholders about the progress and the value delivered by the team.

 A user satisfaction gap exists when there is a difference between what the user expects from a product or service and what the user actually experiences12. The user’s desired outcome is the goal or benefit that the user wants to achieve by using the product or service3. The user’s actual experience is the perception and evaluation of the product or service by the user4. If the user’s actual experience does not meet or exceed the user’s desired outcome, the user will be dissatisfied and may switch to a different product or service. References:

• 1: Identifying and Closing the Customer Satisfaction Gap
• 2: Find the Gaps in Your User Experience
• 3: [Outcome-Driven Innovation]
• 4: [User Experience]
• : Measure Business Opportunities with Unrealized Value

• A. To influence the Total Cost of Ownership of the product: Adhering to the Definition of Done ensures that the product meets the required quality standards, which can influence the Total Cost of Ownership1.
• B. To have transparency into what has been done at the end of each Sprint: The Definition of Done provides a shared understanding of what work was completed and what standards were met as part of the Increment2. This creates transparency and allows the Product Owner to understand what has been accomplished at the end of each Sprint12.

The primary accountability of a Product Owner within the Scrum framework is to maximize the value of the work that the Scrum Team delivers. This involves managing the Product Backlog, but the overarching responsibility is ensuring that the team’s efforts translate into value

The Sprint Backlog is the set of Product Backlog items selected for the Sprint, plus a plan for delivering the product Increment and realizing the Sprint Goal1. The Sprint Backlog is a forecast by the Developers about what functionality will be in the next Increment and the work needed to deliver that functionality into a “Done” Increment2. The Sprint Backlog is a plan with enough detail that changes in progress can be understood in the Daily Scrum2. The Developers modify the Sprint Backlog throughout the Sprint, and the Sprint Backlog emerges during the Sprint. This emergence occurs as the Developers work through the plan and learn more about the work needed to achieve the Sprint Goal2. The Sprint Backlog is not a commitment to deliver a fixed scope of work, but rather a forecast of what the Developers believe they can do in the Sprint3. Therefore, the Sprint Backlog does not need to be fully defined during the Sprint Planning, but only enough so the Developers can create a realistic forecast of what they can do during the Sprint. References: 1: Sprint Backlog, 2: The Scrum Guide, 3: Commitment vs. Forecast