PSPO-II Questions and Answers

= Based on the Evidence-Based Management (EBM) framework, your product has a high Current Value (CV), which means that it delivers value to the existing customers and meets their needs and expectations. However, it also has a high Unrealized Value (UV), which means that there is a large gap between the potential and actual use of the product in the market. This indicates that your product has a low awareness, reach, or appeal among the potential customers who could benefit from it.

To increase the business performance of the product, you need to reduce the UV and increase the Ability to Innovate (A2I), which is the ability to deliver future value. One way to do this is to improve the marketing of the product, which can help you to communicate the value proposition, differentiate the product from the competitors, and attract a greater number of customers. This can also provide you with more feedback and data to inform your product strategy and backlog prioritization.

The other options are not the best actions to take, because they either do not address the root cause of the high UV, or they may compromise the CV or A2I of the product. Increasing the number of product features may not necessarily increase the value or the demand for the product, and it may also increase the complexity and the cost of development. Releasing an identical product with a new name may confuse the customers and dilute the brand identity, and it may also create legal or ethical issues. Dropping the price for the product may not be a sustainable or profitable strategy, and it may also affect the perceived quality or value of the product. References := Professional Scrum Product Owner™ II Certification, Managing Products with Agility, Evidence-Based Management

If Product Backlog items are not sufficiently clear during Sprint Planning, the Developers will typically have difficulty creating a forecast of work for the Sprint (B). This is because the clarity of the Product Backlog items is crucial for the Developers to understand what is expected and to plan their work accordingly. The Scrum framework emphasizes the importance of a well-refined Product Backlog for effective Sprint Planning

 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

In earlier versions of the Scrum Guide, the Daily Scrum was structured around three specific questions:

What did I do yesterday?

What will I do today?

What impediments are blocking my progress?

However, the latest Scrum Guide (2020 and beyond) no longer prescribes these questions. Instead, it emphasizes that the Daily Scrum is an event for the Developers to inspect progress toward the Sprint Goal and adapt their plan as necessary.

Why the Answer is E (None of the Above):

Scrum no longer mandates specific questions for the Daily Scrum.

The focus is on progress toward the Sprint Goal, not on individual work tracking.

Developers decide how they structure the discussion to improve collaboration and planning.

Time spent (Option D) is not relevant to Scrum’s empirical approach, which values outcomes over effort tracking.

Key Scrum Guide Principles Supporting This Answer:

" The Developers can select whatever structure and techniques they want, as long as their Daily Scrum focuses on progress toward the Sprint Goal and produces an actionable plan for the next day of work. "

" The Daily Scrum is not a status meeting; it is an event to inspect progress and adapt the Sprint Backlog as needed. "

Conclusion:

The Scrum Guide does not require specific questions at the Daily Scrum, making Option E ( " None of the above " ) the correct answer.

Focus on Value: Scrum emphasizes delivering increments of value early and often. Each release should focus on a clear outcome for users, even if it doesn ' t encompass every desired feature.

Iterative Approach: Releasing a smaller, focused increment lets you gather feedback, course-correct, and add features incrementally based on what provides the most value.

Stakeholder Management: Involve stakeholders in the prioritization process, explaining the rationale behind focusing on a specific outcome to gather input and secure buy-in.

According to the Scrum Guide, the Scrum Team consists of one Scrum Master, one Product Owner, and Developers. There is no distinction between different types of Developers, such as testers, programmers, designers, etc. The Developers are the people who deliver a potentially releasable Increment of “Done” product at the end of each Sprint. They are accountable for creating and adhering to the Definition of Done, ensuring technical excellence and good design, and collaborating with the Product Owner to maximize value1. Therefore, everyone on the Scrum Team is responsible for ensuring the quality of the product, and there is no specific tester role. However, this does not mean that testing skills are not needed or valued. On the contrary, testing is an essential activity that supports the team and critiques the product throughout the development process2. A professional tester can contribute to the Scrum Team by coaching the team on testing techniques, tools, and practices, helping the team to define clear and unambiguous acceptance criteria, challenging the team to consider different scenarios and edge cases, creating and executing test plans, and providing feedback on the product’s usability, performance, security, and other aspects3. A professional tester can also collaborate with the Product Owner to ensure that the product meets the expectations and needs of the stakeholders and users.

In Scrum, the Product Owner is responsible for maximizing the value of the product by understanding and addressing customer needs effectively. When faced with multiple customer segments using the product in different ways, the best approach is to market the product differently to each group rather than fragmenting the product into multiple versions or ignoring existing customers.

Option A (Evaluate building different products): While segmentation can sometimes justify creating multiple products, it adds complexity in development, maintenance, and resource allocation. Scrum focuses on delivering incremental value in a single product rather than splitting efforts across multiple versions unless there ' s a strong business case.

Option B (Do nothing and invest in future features): This is a risky and reactive approach. Ignoring existing customer groups and only investing in attracting new customers can lead to customer churn and dissatisfaction. A Product Owner should aim for continuous engagement with existing customers to ensure long-term success.

Option C (Keep a single product, but market differently to each group) [Correct Answer]: This aligns with Agile and Scrum principles because it allows the Product Owner to maintain a single product backlog while tailoring marketing messages for different user segments. It helps maximize value delivery without increasing complexity. Instead of fragmenting the product itself, communication and positioning strategies are adjusted to better resonate with different customer types.

Option D (Ensure each release has something for each group): While inclusivity in releases is valuable, forcing every release to cater to all groups can lead to inefficient backlog prioritization. Instead, the Product Owner should balance priorities based on value delivery and strategic goals rather than trying to satisfy all user segments in every release.

A, B, C, and D are correct because they are all measures of the value that a product delivers to the customers and the organization1. Revenue per Employee indicates the efficiency and productivity of the product development2. Market Share shows the competitive advantage and customer satisfaction of the product3. The average selling price as compared to close competitors reflects the perceived value and quality of the product4. Product profitability measures the financial return and viability of the product5. E is incorrect because the weekly velocity of the Developers is not a measure of value, but a measure of output and capacity. Velocity does not indicate whether the product is meeting the needs and expectations of the customers and the stakeholders.

According to the Scrum Guide, the Scrum Team consists of one Scrum Master, one Product Owner, and Developers. The entire Scrum Team is accountable for creating a valuable, useful Increment every Sprint1. The Increment is a concrete step toward achieving the Product Goal, and it must meet the Definition of Done and be usable by the stakeholders1. The Product Owner is accountable for maximizing the value of the product and the work of the Developers1. The Scrum Master is accountable for establishing Scrum as defined in the Scrum Guide, helping everyone understand Scrum theory and practice, and removing impediments to the Scrum Team’s progress1. The Developers are accountable for creating any aspect of a usable Increment each Sprint1. All three roles must collaborate and coordinate their efforts to deliver the best possible product2.

According to the Scrum Guide, the Developers are the people in the Scrum Team who are committed to creating any aspect of a usable Increment each Sprint. They are accountable for creating a plan for the Sprint, the Sprint Backlog, and for adhering to the Definition of Done. The Product Owner and the Scrum Master are not accountable for these activities, but they may support the Developers as needed. The Scrum Team as a whole is accountable for delivering a valuable, useful, and potentially releasable Increment each Sprint, but the Developers have the specific accountability for planning and building it. References := Scrum Guide, Understanding and Applying the Scrum Framework, Managing Products with Agility

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 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]

Sharing people with unique skills across multiple teams will likely result in teams having to wait more often for those people to be available, impeding the delivery of value. This is because those people will have to context-switch between different teams, products, and domains, reducing their focus and efficiency1. Moreover, sharing people with unique skills will create bottlenecks and dependencies in the delivery process, increasing the risk of delays and quality issues2. Furthermore, sharing people with unique skills will discourage teams from developing deep technical skills themselves, making them less cross-functional and self-organizing3. Therefore, the best answer is A.

The other options are not correct because:

B. Teams do not have to develop deep technical skills. This is not a desirable condition, as it contradicts the Scrum value of commitment and the principle of continuous improvement. Teams should strive to develop deep technical skills to deliver high-quality products and to respond to changing requirements and technologies4.

C. Costs are lower since expensive resources are shared. This is not necessarily true, as the costs of context-switching, waiting, and quality issues may outweigh the benefits of sharing resources. Moreover, this option implies a resource-oriented mindset, rather than a value-oriented mindset, which is not aligned with the Scrum framework and the Product Owner role5.

D. More work gets done since people are better utilized. This is not a valid measure of success, as the amount of work done does not reflect the value delivered. Moreover, this option implies a utilization-oriented mindset, rather than an outcome-oriented mindset, which is not aligned with the Scrum framework and the Product Owner role. References: 1: Context Switching, 2: Bottlenecks and Dependencies, 3: Cross-Functional Teams, 4: Technical Excellence, 5: Resource vs. Value Orientation, : Utilization vs. Outcome Orientation

Let ' s break down why the correct answer is C and why the others are incorrect, referencing the Professional Scrum Product Owner™ II (PSPO II) objectives and associated competencies:

C. The Scrum Team is more focused through a common yet specific goal.

Verification: This is the correct answer and aligns perfectly with the purpose of a Sprint Goal as defined in the Scrum Guide and emphasized within the PSPO II competencies.

Explanation and References:

Professional Scrum Competency: Understanding and Applying the Scrum Framework - Applying the Scrum Framework - Empiricism

The Sprint Goal promotes transparency within the team about what they are trying to achieve during the Sprint.

It provides a basis for inspection during the Sprint, allowing the team to adapt their plans based on progress toward the Sprint Goal.

Professional Scrum Competency: Managing Products with Agility - Forecasting and Release Planning

The Sprint Goal helps the team focus on achieving a specific, valuable outcome each Sprint.

It provides a basis for forecasting what can be achieved in the Sprint.

Professional Scrum Competency: Managing Products with Agility - Product Value

The Sprint Goal should be aligned with maximizing product value, providing a clear link between the work done in the Sprint and the overall product vision.

Scrum Guide: The Scrum Guide states, " The Sprint Goal is an objective set for the Sprint that can be met through the implementation of Product Backlog. It provides guidance to the Developers 1 on why it is building the Increment. 2 [...] During Sprint Planning the Scrum Team also crafts a Sprint Goal. The Sprint Goal is an objective set for the Sprint that can be met through the implementation of Product Backlog. " 3 This clearly emphasizes that the Sprint Goal provides focus and guidance.  

A. A Sprint Goal ensures that all the Product Backlog items selected for the Sprint are implemented.

Verification: This is incorrect.

Explanation and References:

Professional Scrum Competency: Understanding and Applying the Scrum Framework - Applying the Scrum Framework - Empiricism

Scrum acknowledges that the plan for the Sprint (what Product Backlog items are chosen) may change as the team learns more during the Sprint.

The Sprint Goal is the commitment, and while the team strives to complete the selected Product Backlog items, the primary focus is on achieving the Sprint Goal, even if it means adapting the plan.

Scrum Guide: While the selected Product Backlog items are the initial plan, the Scrum Guide states, " The selected Product Backlog items deliver one coherent function, which can be the Sprint Goal. " This implies that the focus is on the coherent function (represented by the Sprint Goal), not necessarily the completion of every single Product Backlog item.

B. A Sprint Goal only gives purpose to Sprint 1.

Verification: This is incorrect.

Explanation and References:

Professional Scrum Competency: Managing Products with Agility - Forecasting and Release Planning

Every Sprint should have a Sprint Goal, providing ongoing direction and focus for the team.

Scrum Guide: The Scrum Guide explicitly states that a Sprint Goal is crafted during Sprint Planning, implying that it ' s a necessary component of every Sprint, not just Sprint 1.

D. Sprint Goals are not valuable. Everything is known from the Product Backlog.

Verification: This is incorrect.

Explanation and References:

Professional Scrum Competency: Managing Products with Agility - Product Value

Sprint Goals are crucial for maximizing product value by providing focus and ensuring the team is working on the most important aspects in each Sprint.

Professional Scrum Competency: Understanding and Applying the Scrum Framework - Applying the Scrum Framework - Empiricism

The Sprint Goal provides context and purpose beyond the individual Product Backlog items. It helps the team understand the " why " behind the work.

Scrum Guide: The Scrum Guide ' s emphasis on the Sprint Goal throughout the Sprint lifecycle (planning, daily Scrum, review, retrospective) demonstrates its importance.

In conclusion, the Sprint Goal serves as a unifying and focusing mechanism for the Scrum Team, promoting commitment to a specific outcome within each Sprint and is, therefore, a crucial element for successful Scrum implementation, aligning perfectly with the PSPO II competencies and the Scrum Guide.

= As a Product Owner, you are accountable for maximizing the value of the product and the work of the Developers. To do this, you need to have a clear vision of the product and its target users, as well as a validated understanding of the market opportunities and risks. You also need to collaborate with stakeholders and customers to align their expectations and feedback with the product goals and strategy.

In this scenario, you face a dilemma between pursuing a new market segment or satisfying the existing customers. Both options have potential value, but also uncertainty and trade-offs. The best way to proceed is to devise an experiment that will help you to test your assumptions and learn more about the new market and its potential. This could be a small-scale release, a prototype, a survey, or any other method that can provide you with empirical evidence and feedback. By doing this, you can reduce the risk of investing in a feature that may not deliver the expected value, and also gain insights that can help you to refine your product vision and backlog.

This approach is consistent with the principles of agile product management, which emphasize delivering value early and often, validating hypotheses with data, and adapting to changing customer needs and market conditions. It also demonstrates your ability to apply the Scrum values of openness, courage, and respect, as you are willing to explore new possibilities, challenge your own opinions, and involve your stakeholders and customers in the decision-making process. References := Scrum Guide, Managing Products with Agility, Evidence-Based 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.

Personas are fictional characters that represent the different user types that might use your product or service in a similar way1. Personas can help you to2345:

Understand the needs of a set of users by creating empathy and insight into their goals, behaviors, and pain points.

Formulate hypotheses about product value by identifying the problems and opportunities that your product can address for each user type.

Understand market potential by estimating the size and characteristics of each user segment and their willingness to pay for your product.

Discover key buying triggers by exploring the motivations, influences, and decision-making processes of each user type.

Design and test your product features and user experience by using personas as a guide and a reference point. References:

1: Personas – A Simple Introduction

2: The Complete Guide to User Personas and How They Can Help Your Marketing Strategy (With Examples)

3: Personas | Usability.gov

4: The importance of personas for digital experience

5: Personas | Definition and Overview

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 burndown chart is a graphical tool that shows the amount of work remaining versus time. It is often used to track the progress of a Sprint or a release. The work remaining is usually measured in terms of effort, such as hours or story points, and it is plotted on the vertical axis. The time is measured in terms of days or weeks, and it is plotted on the horizontal axis. The burndown chart starts with the total amount of work at the beginning of the Sprint or release, and it ideally ends with zero work at the end. The slope of the burndown chart indicates the rate of progress, or the velocity, of the Scrum Team12.

The other options are not what burndown charts track. Accumulated cost, accumulated business value, and individual worker productivity are not relevant or useful metrics for Scrum Teams, as they do not reflect the value or the quality of the product. Scrum Teams focus on delivering potentially releasable increments of the product that meet the Definition of Done, and they use empirical feedback to inspect and adapt their work13. References: 1: Understanding and Applying the Scrum Framework 2: Burndown Chart 3: Managing Products with Agility

The Professional Scrum Product Owner™ II (PSPO II) emphasizes the importance of a strategic approach to product management. According to the PSPO II resources, it is essential to:

Continually measure the impact of new investments or marketing efforts for both products (Option A). This aligns with the PSPO II focus on evidence-based management and making decisions based on empirical data.

Invest in Product A to increase its market share, customer satisfaction, and revenue (Option B). The PSPO II materials suggest that a product with a greater potential market but lower customer satisfaction requires attention to improve its standing and capitalize on its market potential.

Investigate an increase in marketing for Product B to grow its market share (Option C). Even though Product B is currently generating more revenue, the PSPO II guides recommend exploring opportunities to expand its market share, which could lead to even greater revenue.

Therefore, a comprehensive investment strategy that includes all the above actions is recommended for managing products with agility, as per the PSPO II guidelines. This approach ensures that both products are given the opportunity to maximize their market potential while maintaining a focus on customer satisfaction and revenue growth. It’s a holistic strategy that considers the different strengths and opportunities of each product.

A. Reorder items in the Product Backlog: The Product Owner is responsible for ordering the Product Backlog to maximize value12.

B. Answer questions from the Developers about items in the current Sprint: The Product Owner is engaged throughout the sprint, answering questions on how things are supposed to function and look4.

E. Gather information and opinions from stakeholders: Gathering information and opinions from stakeholders is a key activity for the Product Owner, as it helps in understanding the value and ordering the Product Backlog

According to the Scrum Guide, the Developers are accountable for creating a plan for the Sprint, which includes selecting the Product Backlog items that they can deliver in the Sprint1. If they realize that the workload is too high, they have two options: either reduce the scope or increase the capacity. Reducing the scope means removing or changing some of the Product Backlog items, in agreement with the Product Owner, so that the Sprint Goal can still be achieved2. Increasing the capacity means adding more Developers to the team, but this is not recommended, as it can disrupt the team dynamics, lower the quality, and increase the communication overhead3. Therefore, the best actions to take are A and B, as they respect the self-organization and collaboration of the Scrum Team, and allow them to deliver a valuable and potentially releasable Increment at the end of the Sprint4.