Pass the Scrum PSPO PSPO-II Questions and answers with CertsForce

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.

The scenario describes a product with low Current Value and high Unrealized Value, meaning that while the product is not currently delivering significant value, there is potential for substantial improvement.

Additionally:

A high product cost ratio (85%) means that a large portion of revenue is being consumed by operating costs, leaving little room for new development.

A long time-to-market suggests inefficiencies in the development and delivery process, preventing rapid iteration and improvement.

Given these conditions, the best long-term strategy is to address the underlying inefficiencies before attempting to innovate.

Analysis of Answer Choices:

Option A: Drop the product (Incorrect)

Abandoning the product is premature, as the Unrealized Value is high.

High Unrealized Value indicates potential customer demand or market opportunity that has not yet been tapped.

A Product Owner should first explore ways to unlock that value before considering discontinuation.

Option B: Improve efficiency by eliminating waste (Correct)

Addressing inefficiencies in product development, delivery, and cost structure is a fundamental step before attempting new innovations.

By reducing waste, improving operational efficiency, and lowering costs, the team can free up resources to invest in new high-value features.

Scrum and Agile emphasize continuous improvement—optimizing processes enables faster, more cost-effective feature development in the future.

Option C: Focus on high-value features despite inefficiencies (Incorrect)

While prioritizing high-value features is important, the lack of capacity and long time-to-market would limit the effectiveness of this strategy.

Without first improving efficiency, the product will continue to struggle with slow delivery, high costs, and missed opportunities.

Key Scrum and Agile Principles Supporting This Answer:

Continuous Improvement: Scrum promotes regular inspection and adaptation to optimize processes and eliminate waste.

Sustainable Development: Focusing on long-term product viability requires fixing systemic inefficiencies before pursuing new growth.

Empirical Process Control: Decisions should be based on data; the data here suggests inefficiencies are a major blocker to success.

Conclusion:

The best approach is to first improve efficiency by eliminating waste, reducing costs, and accelerating time-to-market. Once the team has built a solid foundation, they can then focus on innovation and unlocking the Unrealized Value of the product.

According to the Scrum Guide, the purpose of the Sprint Retrospective is to plan ways to increase quality and effectiveness. The Scrum Team inspects how the last Sprint went with regards to individuals, interactions, processes, tools, and their Definition of Done1. Therefore, all of the options A, B, C, and D are possible topics that the Scrum Team might discuss during a Sprint Retrospective, as they relate to the aspects that the team can improve or adapt. For example, the team might discuss how to communicate better, how to plan the Sprint more effectively, how to acquire new skills or knowledge, or how to update their Definition of Done23. The Sprint Retrospective is a formal opportunity for the team to focus on inspection and adaptation, and to identify the most helpful changes to implement in the next Sprint1.

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

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

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

The Sprint Backlog is one of the three Scrum artifacts, alongside the Product Backlog and the Increment. It is a dynamic plan that contains:

The selected Product Backlog items for the Sprint.

A plan for delivering the Increment and achieving the Sprint Goal.

The tasks and work needed to complete the selected items.

The Scrum Guide explicitly states that the Sprint Backlog is owned and managed solely by the Developers.

Analysis of Answer Choices:

Option A: The Developers (Correct)

The Developers create, maintain, and update the Sprint Backlog throughout the Sprint.

They have full ownership over their work and the plan required to meet the Sprint Goal.

As self-managing professionals, only the Developers decide how to accomplish their work.

Option B: The Scrum Master (Incorrect)

The Scrum Master is a servant leader and coach, not responsible for managing the Sprint Backlog.

They help the Scrum Team understand and follow Scrum practices, but they do not own or control artifacts.

Option C: The Product Owner (Incorrect)

The Product Owner manages the Product Backlog, ensuring it is prioritized to maximize value.

However, they do not dictate how work is done in a Sprint or modify the Sprint Backlog.

Option D: The Scrum Team (Incorrect)

While the Scrum Team (Developers, Product Owner, and Scrum Master) collaborates, the Sprint Backlog belongs exclusively to the Developers.

Key Scrum Guide Principles Supporting This Answer:

" The Sprint Backlog is a plan by and for the Developers. It is highly visible, real-time, and should be adapted as needed throughout the Sprint. "

" Only the Developers can change the Sprint Backlog during a Sprint. "

Conclusion:

The Developers are fully responsible for the Sprint Backlog. They create, modify, and own the plan to meet the Sprint Goal, ensuring agility and self-management.

The Product Owner is accountable for effective Product Backlog management. The 2020 Scrum Guide states that this includes creating and clearly communicating Product Backlog items .

So the accountable person is clearly the Product Owner .

Why D is the best answer:

Option D identifies the Product Owner , which is the key official answer. However, the wording about a “proxy” is not the exact Scrum Guide wording. The Scrum Guide says the Product Owner may delegate the responsibility to others , but the Product Owner remains accountable . So while the option is not perfectly phrased, it is still the best available answer because it correctly names the Product Owner as the accountable person.

Why A is incorrect:

Developers may help refine, clarify, and break down Product Backlog Items, but they are not the accountable role for clearly expressing them.

Why B is incorrect:

The Scrum Master is not accountable for clearly expressing Product Backlog Items. The Scrum Master helps the Scrum Team understand Scrum and supports effectiveness, but Product Backlog accountability belongs to the Product Owner.

Why C is incorrect:

This wrongly assigns accountability to the Scrum Master. That is not supported by the Scrum Guide.

Why E is incorrect:

Again, this incorrectly makes the Scrum Master accountable.

Important correction to the option wording:

The official Scrum wording is not “appoint a proxy.” The correct concept is:

The Product Owner may delegate the work , but remains accountable .