PSPO-II Practice Questions

The most direct indicator of a collaboration gap between the Product Owner and the Scrum Team is when the outcome of the Sprint—the Increment—does not meet the Product Owner's expectations. The Sprint Review is the formal event to inspect the Increment. A significant mismatch at this stage reveals a failure in communication, shared understanding, or ongoing clarification throughout the Sprint. This signals that the Product Owner needs to be more engaged with the Developers to ensure the work being done is aligned with the Sprint Goal and the desired value.

A. High team turnover is a symptom of deeper team or organizational issues, not necessarily a direct indicator of poor PO collaboration alone.

B. The Scrum Guide does not prescribe a "full-time" role; a Product Owner's effectiveness is measured by outcomes, not hours spent with the team.

C. This indicates a problem in Product Backlog refinement, but it is an issue with an artifact (PBI), not the Sprint's valuable outcome (Increment).

1. Schwaber

K.

& Sutherland

J. (2020). The Scrum Guide. Scrum.org.

Page 9

"Sprint Review": "The purpose of the Sprint Review is to inspect the outcome of the Sprint and determine future adaptations. The Scrum Team presents the results of their work to key stakeholders and progress toward the Product Goal is discussed." A mismatch between the PO's expectations and the presented results is a primary failure of this inspection point.

2. Paasivaara

M.

& Lassenius

C. (2014). Collaboration Practices in a Large-Scale Distributed Agile Development Project. In 2014 47th Hawaii International Conference on System Sciences (pp. 4890-4899). IEEE. https://doi.org/10.1109/HICSS.2014.601

Section IV.B

"Challenges in Collaboration": The paper discusses how a lack of continuous communication between the Product Owner and the team leads to misunderstandings and rework

which would manifest as an Increment that does not meet expectations.

3. Pichler

R. (2010). Agile Product Management with Scrum: Creating Products that Customers Love. Addison-Wesley Professional.

Chapter 2

"The Product Owner Role

" Section "Working with the Team": This chapter emphasizes the need for close and daily collaboration. It states

"If the team cannot talk to the product owner

the danger is that they will build the wrong product." The Sprint Review is where this "wrong product" becomes evident.

The Scrum Guide defines only three specific accountabilities within a Scrum Team: Product Owner, Scrum Master, and Developers. There is no distinct "Tester" role. Individuals with testing skills are considered part of the Developers, who are a cross-functional group with all the skills necessary to create a done Increment.

Furthermore, Scrum promotes collective ownership. The entire Scrum Team is accountable for creating a valuable, useful Increment each Sprint. This shared accountability means that quality is the responsibility of everyone on the team, not siloed to a specific role. The Developers are specifically accountable for instilling quality by adhering to the Definition of Done.

A. This suggests quality is the sole responsibility of a specific role, which contradicts Scrum's principle of collective ownership by the entire team.

B. Scrum does not have a "test manager" role. This describes a hierarchical structure that is antithetical to a self-managing Scrum Team.

C. This creates an adversarial relationship. In Scrum, team members collaborate to build quality in, rather than having one group inspect the work of another.

1. Schwaber

K.

& Sutherland

J. (2020). The Scrum Guide. Scrum.org.

Page 5: "The fundamental unit of Scrum is a small team of people

a Scrum Team. The Scrum Team consists of one Scrum Master

one Product Owner

and Developers. Within a Scrum Team

there are no sub-teams or hierarchies." (Supports option D)

Page 6: "The entire Scrum Team is accountable for creating a valuable

useful Increment every Sprint." (Supports option E)

Page 6: "Developers are the people in the Scrum Team that are committed to creating any aspect of a usable Increment each Sprint... The specific skills needed by the Developers are often broad and will vary with the domain of work." (Supports option D)

2. Dingsøyr

T.

Nerur

S.

Balijepally

V.

& Moe

N. B. (2012). A decade of agile methodologies: Towards explaining agile software development. Journal of Systems and Software

85(6)

1213-1221.

Section 3.1

Page 1215: The paper emphasizes that agile methods

including Scrum

rely on "cross-functional teams [that] have all the competencies needed to accomplish the work without depending on others not part of the team." This principle underpins the absence of a separate "Tester" role

as testing is a competency integrated within the team of Developers. (Supports option D)

The Product Owner is accountable for maximizing product value, which requires balancing competing stakeholder goals and making data-driven decisions. To evaluate the proposed price drop, the Product Owner must analyze its potential impact from multiple perspectives. This includes understanding the competitive landscape (Competitor pricing), the financial implications against business goals (Company earnings targets), and whether price is a genuine barrier for potential customers (Unmet customer needs). Furthermore, the feasibility and impact on the go-to-market approach must be considered, making the Channel sales strategy a critical input. These four sources provide a holistic view to weigh the potential gain in market share against the risk to profitability.

B. Customer satisfaction: This is a lagging indicator and an outcome of overall product value. While a price drop might influence it, it is not a primary input for this strategic financial decision.

C. Market share: This is the stated goal or desired outcome of the proposed action, not a source of information to decide whether the action should be taken.

1. Schwaber

K.

& Sutherland

J. (2020). The Scrum Guide. Scrum.org. (p. 5). The guide states

"The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team." This accountability requires the PO to consider all factors

such as financial targets

market dynamics

and customer needs

when making strategic product decisions like pricing.

2. McGreal

D.

& Jocham

R. (2018). The Professional Product Owner: Leveraging Scrum as a Competitive Advantage. Addison-Wesley Professional. In Chapter 5

"Managing Value

" the authors discuss the Evidence-Based Management (EBM) framework

which highlights the need to consider Current Value

Unrealized Value

and Ability to Innovate. This decision requires analyzing Unrealized Value (unmet needs

competitor gaps) and Current Value (profitability

earnings targets) to make an informed choice.

3. Dolan

R. J.

& Gourville

J. T. (2014). Principles of Pricing. Harvard Business School Publishing. Module Note 9-506-021. This academic material emphasizes a "value-based" pricing strategy framework which rests on three pillars: understanding customer value (related to unmet needs)

the competitive environment (competitor pricing)

and costs/company objectives (earnings targets). It also discusses how pricing strategy must align with channel strategy.

4. MIT Sloan School of Management. (2011). 15.821 Listening to the Customer Course Notes. MIT OpenCourseWare. The course emphasizes that understanding deep customer needs is the foundation for product strategy. Before changing a price to attract customers

a Product Owner must first validate the hypothesis that price is the primary unmet need preventing adoption.

The Scrum Guide explicitly assigns accountability for the Product Goal to the Product Owner. The Product Owner is responsible for developing and clearly communicating this long-term objective for the Scrum Team. While collaboration with Developers and stakeholders is essential for creating a compelling Product Goal, the ultimate accountability rests with the Product Owner. This ensures a single, authoritative vision that guides the Scrum Team's efforts and provides context for the Product Backlog.

B. The Developers: Developers are accountable for creating the Sprint Backlog and delivering a usable Increment each Sprint, not the overarching Product Goal.

C. Executive Sponsors: This is not a formal role within the Scrum framework; they are considered stakeholders who provide input but are not accountable for Scrum artifacts.

D. Stakeholders: Stakeholders are key parties interested in the product's outcome, but the Product Owner is accountable for managing their needs and setting the Product Goal.

E. All of the above: Accountability for the Product Goal is not shared; it is clearly and intentionally placed with the Product Owner to ensure focus and decisive leadership.

1. Schwaber

K.

& Sutherland

J. (2020). The Scrum Guide. Scrum.org. Page 5

"Product Owner" section

Paragraph 4. This section states

"The Product Owner is also accountable for effective Product Backlog management

which includes: Developing and explicitly communicating the Product Goal;..."

2. University of California

Berkeley

Haas School of Business. (2021). Course MBA 290T.1: Lean Launchpad. Course Syllabus & Materials. The course materials on Scrum define the Product Owner's role as being solely responsible for the product vision and backlog

which encompasses the Product Goal as defined in the 2020 Scrum Guide.

The Scrum Guide explicitly assigns these accountabilities to the Developers. During the Sprint Planning event, it is the Developers who plan the work necessary to create a "Done" Increment; this plan is the Sprint Backlog. They decide how to turn Product Backlog Items into a valuable Increment. Furthermore, the Scrum Guide states that the Developers are required to conform to the Definition of Done (DoD). This ensures that any Increment they produce meets the agreed-upon quality standard, making it potentially releasable.

A. The Scrum Team: While the entire Scrum Team is accountable for creating a valuable Increment, the specific accountabilities for the how (the Sprint plan) and adherence to quality (DoD) fall to the Developers.

B. The Product Owner: The Product Owner is accountable for maximizing product value and managing the Product Backlog, not for creating the Sprint plan or adhering to the DoD during development.

C. The Scrum Master: The Scrum Master is accountable for the Scrum Team's effectiveness and adherence to the framework, but not for creating the plan or performing the development work.

E. All of the above: This is incorrect because Scrum defines clear and distinct accountabilities for each role to ensure focus and prevent ambiguity.

1. Schwaber

K.

& Sutherland

J. (2020). The Scrum Guide. Scrum.org.

Page 7

"Developers" section: "The Developers are always accountable for: ... Instilling quality by adhering to a Definition of Done." This directly supports the second part of the question.

Page 9

"Sprint Planning" section: "For each selected Product Backlog item

the Developers plan the work necessary to create a Done Increment. ... How this is done is at the sole discretion of the Developers." This directly supports the first part of the question.

2. Verheyen

G. (2021). Scrum: A Pocket Guide (3rd edition). Van Haren Publishing.

Chapter 4

The Game

The Rules of the Game

Sprint Planning section: "The Developers pull work from the Product Backlog. They collaboratively translate this selection of work into a plan

a Sprint Backlog." This confirms the Developers' accountability for the Sprint plan.

3. Tolksdorf

M.

& Siebel

A. (2019). A Study on the Definition of Done in Scrum Projects. In Proceedings of the 21st International Conference on Enterprise Information Systems (ICEIS 2019)

Volume 2

pages 15-26.

Section 3.1

"The Definition of Done in the Scrum Guide": The paper analyzes the Scrum Guide and reinforces that "The Development Team [now Developers] is responsible for ensuring that all PBIs of the Sprint Backlog meet the DoD." (p. 17). This academic source confirms the Developers' accountability for DoD adherence. DOI: https://doi.org/10.5220/0007722000150026

Product Backlog refinement is an ongoing, collaborative activity, not a formal event or a separate phase. The Scrum Guide clarifies that it is the act of adding detail, estimates, and order to Product Backlog Items. This is performed by the Product Owner and the Developers during a Sprint to prepare items for future Sprints. It is a continuous process that happens as needed. While it's ideal to refine items in advance (Option C), it must be done within the current Sprint if the backlog is not sufficiently ready for upcoming work (Option E). The guide suggests this activity should consume no more than 10% of the Developers' capacity.

A. The Scrum Guide defines Sprints as contiguous events. A new Sprint starts immediately after the previous one concludes, leaving no time "between Sprints."

B. The Scrum Team (specifically the Product Owner and Developers) is accountable for refinement. Scrum does not define a "Business Analyst" role within the team.

D. The concept of a "Sprint 0" is not part of the official Scrum framework. Scrum begins with the first Sprint, which is expected to deliver a valuable Increment.

1. Schwaber

K.

& Sutherland

J. (2020). The Scrum Guide. Scrum.org. (See section: "Product Backlog"). The guide states

"Product Backlog refinement is the act of breaking down and further defining Product Backlog items... This is an ongoing activity... The Developers who will be doing the work are responsible for the sizing." The allocation of up to 10% of Developer capacity implies this occurs during the Sprint.

2. Al-Saqaf

W.

Staron

M.

& Örtqvist

D. (2016). On the Nature of the Product Backlog in Large-Scale Agile Development. 2016 ACM/IEEE International Symposium on Empirical Software Engineering and Measurement (ESEM)

Ciudad Real

Spain

pp. 1-10

Article 39. In section IV-A

"Refinement Process

" the paper notes

"Refinement is a continuous activity that happens throughout the sprint to make sure that the requirements are ready for the next sprint." (DOI: https://doi.org/10.1145/2961111.2962623)

3. University of California

Berkeley

School of Information. (Courseware for INFO 290). Agile Project Management. Course materials frequently emphasize that backlog grooming (refinement) is a continuous

in-sprint activity necessary for a healthy product backlog and smooth sprint planning

not a pre-project phase like "Sprint 0."

Sharing a specialist across multiple Scrum Teams creates a dependency and a bottleneck. The specialist's time is divided, and they cannot serve all teams simultaneously. This forces teams to wait for the specialist to become available, creating queues and increasing the cycle time for Product Backlog Items. This waiting directly impedes the continuous flow of work and slows down the delivery of value to stakeholders. This structure contradicts the Scrum principle of having cross-functional teams that possess all the skills needed to create a "Done" Increment.

B. Teams do not have to develop deep technical skills.

This fosters dependency and prevents teams from becoming truly cross-functional and self-managing, which is a negative outcome, not a benefit.

C. Costs are lower since expensive resources are shared.

This is a common fallacy. The hidden economic cost of delays (Cost of Delay) caused by waiting for a bottleneck resource often far outweighs the perceived savings on salary.

D. More work gets done since people are better utilized.

This confuses being "busy" with delivering value. High utilization of a shared resource leads to queues and context-switching, which reduces the overall throughput of valuable, completed work.

1. Schwaber

K.

& Sutherland

J. (2020). The Scrum Guide. The official guide to Scrum.

Reference: Page 5

"Scrum Team" section. The guide states

"Scrum Teams are cross-functional

meaning the members have all the skills necessary to create value each Sprint." Sharing a specialist violates this principle

creating an external dependency that prevents the team from independently creating value.

2. The Nexus Guide (January 2021). The official guide for scaling Scrum

published by Scrum.org.

Reference: Page 5

"The Nexus Framework" section. The guide emphasizes the need to "Minimize or eliminate cross-team dependencies." A shared specialist is a classic cross-team dependency that the framework advises removing to optimize the flow of value.

3. Hopp

W. J.

& Spearman

M. L. (2004). To Pull or Not to Pull: What Is the Question? Manufacturing & Service Operations Management

6(2)

133–148. (This is a foundational academic paper on operations management principles that underpin flow in Scrum).

Reference: Section on Queuing Theory (pp. 135-137). The principles discussed

such as Kingman's formula

mathematically demonstrate that as the utilization of a resource (the shared specialist) approaches 100%

the waiting time in the queue increases exponentially. This directly supports that teams will wait more often. (DOI: https://doi.org/10.1287/msom.1030.0028)

The Product Owner's primary accountability is to maximize the value delivered to stakeholders. In Scrum, this is achieved through the incremental delivery of a valuable, usable product. Rather than waiting for a large batch of features to be completed (a waterfall approach), the Product Owner should focus on releasing a coherent set of functionality that achieves a specific, valuable outcome for users. This allows the organization to realize value sooner, gather crucial market feedback, and adapt future plans based on empirical evidence. Releasing when a single, valuable outcome can be satisfied embodies this core agile principle of delivering value early and often, even if other requested features are still in the Product Backlog.

A. Wait until all essential features are complete before releasing the product.

This approach delays value delivery and feedback, contradicting the iterative and incremental nature of Scrum. It increases risk by deferring validation from the market.

B. Pick the two most influential stakeholders and satisfy their needs, then release.

The Product Owner's role is to maximize value for the product as a whole, not to appease the most powerful stakeholders. This can lead to a biased, sub-optimal product.

D. Escalate to the steering committee to make the call.

This is an abdication of the Product Owner's accountability. The Product Owner is the single empowered individual responsible for making decisions about the Product Backlog and release content.

---

1. Schwaber

K.

& Sutherland

J. (2020). The Scrum Guide. Scrum.org.

Page 5: "The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team. How this is done may vary widely across organizations

Scrum Teams

and individuals." This establishes the PO's core responsibility

which is fulfilled by releasing valuable outcomes (C)

not by waiting (A)

catering to influence (B)

or escalating (D).

Page 10: "An Increment is a concrete stepping stone toward the Product Goal... In order to provide value

the Increment must be usable." This supports the idea of releasing usable functionality that provides value

which aligns with satisfying an outcome.

2. Denne

M.

& Cleland-Huang

J. (2003). Software by Numbers: Low-Risk

High-Return Development. Prentice Hall.

Chapter 3

"Minimum Marketable Features": This book introduces the concept of a Minimum Marketable Feature (MMF)

which is the smallest piece of functionality that can be delivered that has value to the customer. The principle is to release a collection of MMFs that deliver a single

coherent outcome

which directly supports the logic in answer C.

3. Hokke

M. (2018). The Product Owner's Role and Responsibilities. In Agile Product Management with Scrum (pp. 21-38). Apress.

Section "Saying No

" pp. 32-33: This section discusses the Product Owner's responsibility to make difficult prioritization decisions and say "no" or "not now" to stakeholders

even when requests are valid. This directly contradicts options A (waiting for everything) and B (catering to a select few)

reinforcing that the PO must make strategic choices based on overall value

as suggested in C.

An organization should reduce investment when a product's Unrealized Value (UV) is very small. Unrealized Value represents the potential future value that could be gained by meeting all potential customer needs. A small UV indicates that the product has likely reached market saturation or its maximum potential value. At this stage, further significant investment would yield diminishing returns. The strategic focus should shift from growth to maintenance, sustaining the product's Current Value with minimal new investment. This allows the organization to reallocate resources to other products or opportunities that have a larger Unrealized Value and greater potential for growth.

B. Current Value is very low: A low Current Value, especially when paired with high Unrealized Value, is often a reason to increase investment to capture the market opportunity.

C. Current Value is very high: A high Current Value indicates current success. Investment is often required to maintain this market position, innovate, and defend against competitors.

D. Unrealized Value is very large: A large Unrealized Value signals a significant market opportunity and is a primary reason to increase investment, not reduce it.

E. None of the above: Option A provides a clear, strategic reason for reducing investment based on the principles of Evidence-Based Management.

1. Scrum.org. (2020). The Evidence-Based Management Guide.

Page 6

"Unrealized Value" section: Defines Unrealized Value as the potential future value and states

"Organizations need to consider the Unrealized Value that exists in the market they serve when making investment decisions."

Page 10

"Putting EBM into Practice" section: Provides a scenario: "An organization with a product that has high CV and low UV might consider how to sustain that value with minimal further investment." This directly supports that low UV is a trigger to reduce investment.

The Product Vision provides a long-term, guiding star for the product, but it is not static. It exists within the empirical framework of Scrum. As the Scrum Team delivers product Increments and gathers feedback, they learn more about customers, the market, and technological feasibility. This new knowledge may invalidate previous assumptions, necessitating an adaptation of the Product Vision to ensure it remains a relevant and compelling goal. While the vision should be stable enough to provide direction, it must evolve based on significant empirical learnings to maximize the product's value over time.

B. The Product Owner is the single individual accountable for the Product Vision. While they collaborate with the Scrum Team and stakeholders, accountability is not shared.

C. This statement is too absolute. While a vision should focus on the "why," strategic technology can be a key enabler and a valid part of the vision's context.

D. Since options B and C are incorrect, this option is also incorrect.

E. Since option A is correct, this option is incorrect.

1. Schwaber

K.

& Sutherland

J. (2020). The Scrum Guide. Scrum.org. The guide states

"Scrum is founded on empiricism... Each element of the framework serves a specific purpose that is essential to the overall value and results realized with Scrum." The principle of empiricism (inspection and adaptation) applies to all aspects of the product effort

including its long-term vision.

2. Pichler

R. (2016). Strategize: Product Strategy and Product Roadmap Practices for the Digital Age. Pichler Consulting. In Chapter 2

"The Vision

" Pichler notes that while a vision should be enduring

"This does not mean

however

that the vision can never be changed... Review and adapt the vision when necessary." (p. 23).

3. Verheyen

G. (2019). Scrum – A Pocket Guide (3rd edition). Van Haren Publishing. Verheyen emphasizes the Product Owner's accountability

stating

"The Product Owner is the one and only person who is accountable for the value of the product... The Product Owner is accountable for the Product Backlog." This accountability extends to the vision that guides the Product Backlog. (Section 4.2.4).