Free PSPO-II Practice Test Questions and Answers (2026)

The Product Backlog is an emergent, ordered list of what is needed to improve the product. According to the Scrum Guide, the Product Owner is strictly accountable for effective Product Backlog management, which explicitly includes ordering the items to maximize the overall value of the product. Furthermore, transparency is a core empirical pillar of the Scrum framework. To enable proper inspection and adaptation, the Product Backlog must be highly visible, transparent, and clearly understood by both the Scrum Team and the relevant stakeholders. This continuous visibility ensures that everyone shares a common understanding of the product's future direction and the specific work planned to achieve the overarching Product Goal.

C: The Scrum Guide does not mandate any specific format, such as user stories, for Product Backlog items; teams may use any format that provides clarity. D: The Product Backlog is dynamic and emergent; it is never complete and constantly evolves as the product and environment change, meaning items are added continuously. E: While the Product Owner is accountable for the Product Backlog, they may delegate the actual work of creating and placing items on it to others, such as the Developers. F: The Product Backlog does not replace direct communication; Developers are highly encouraged to collaborate directly with stakeholders to gain deeper empathy and technical clarity.

1. Scrum Guide 2020

Section: Product Backlog

Page 10.

2. Scrum Guide 2020

Section: Product Owner

Page 5.

Personas are fictional, archetypal characters created to represent the different user types that might use a site, brand, or product in a similar way. In the context of Scrum and Product Management, personas are highly versatile tools. They primarily help the Scrum Team understand the specific needs, goals, and pain points of a target user group. Furthermore, by understanding these users deeply, the Product Owner can formulate testable hypotheses about what features will deliver the most product value. Personas also assist in evaluating market potential by identifying the size and demographics of these user segments, and they reveal key buying triggers by mapping out the user's motivations and decision-making processes. Therefore, all the listed options represent valid and valuable applications of personas.

A: Incorrect because it is only one part of what personas do; they also help with hypotheses, market potential, and buying triggers. B: Incorrect because while true, it is incomplete. Personas also aid in understanding user needs and market dynamics. C: Incorrect as it ignores the user-centric design and value hypothesis benefits of personas. D: Incorrect because discovering buying triggers is just one facet of persona utilization, not the complete picture.

1. Pichler, R. (2010). Agile Product Management with Scrum: Creating Products that Customers Love. Addison-Wesley Professional. (Chapter 2: Envisioning the Product, Section: Describing the Target Audience with Personas, pp. 35-39).

2. Scrum.org. (2020). Professional Scrum Product Owner Subject Areas: Focus on Value. (Section: Understanding Customers and Users).

Discovering that features are rarely used indicates a gap between assumed value and actual Current Value. To evaluate this, a Product Owner must employ empirical approaches as outlined in Evidence-Based Management (EBM). Running experiments (C) and disabling unused features to monitor user reactions (B) are practical ways to gather behavioral data and test hypotheses about feature necessity. Additionally, engaging directly with users to understand their desired outcomes (A) provides qualitative insights into why the features missed the mark. Finally, examining whether the features actually solve the intended problem (D) helps determine if the issue lies in the feature's execution, its discoverability, or if the underlying customer problem was misunderstood from the beginning.

N/A: All provided options are correct and represent valid empirical actions a Product Owner should take to evaluate unexpected feature usage results.

1. Evidence-Based Management (EBM) Guide 2020 (Section: Experimentation, p. 9).

2. Evidence-Based Management (EBM) Guide 2020 (Section: Current Value, p. 5).

All five activities are legitimate aspects of Product Backlog management. The Scrum Guide defines Product Backlog refinement as "the act of breaking down and further defining Product Backlog items into smaller more precise items" and adding detail such as a description, order, and size (D, E, A). The Product Owner is accountable for ordering the Product Backlog (E). Collaborating with stakeholders to review and validate the Product Backlog ensures the right value is maximized (C). Reducing dependencies between items (B) makes them more independent, enabling flexible ordering and smoother delivery each Sprint. Attendees of the backlog typically estimate/forecast effort (A). Since Product Backlog management encompasses defining, ordering, refining, and collaborating with stakeholders, every listed option is a valid managing activity.

None — all options are correct Product Backlog management activities.

1. Schwaber

K. & Sutherland

J. (2020). The Scrum Guide

p. 6 ("Product Backlog" section) — defines refinement

ordering

sizing

and detail (supports A

D

E). https://scrumguides.org/scrum-guide.html

2. Schwaber

K. & Sutherland

J. (2020). The Scrum Guide

p. 5–6 ("Product Owner" accountability) — ordering and maximizing value via backlog management (supports C

E).

3. Schwaber

K. & Sutherland

J. (2020). The Scrum Guide

p. 6 ("Commitment: Product Goal") — stakeholder collaboration to validate value (supports C).

4. Scrum.org

Professional Scrum Product Owner – Evidence-Based Management Guide (2024)

Section "Managing Product Value" — stakeholder review of backlog items (supports C).

5. Scrum.org

The Product Owner Learning Path / PSPO Open Assessment — managing dependencies and item independence for predictable delivery (supports B). https://www.scrum.org/resources

The Definition of Done (DoD) is a formal description of the state of the Increment when it meets the quality measures required for the product. Its primary purpose is to increase transparency by ensuring everyone has a shared understanding of what "complete" means for any given Product Backlog item. Furthermore, by clearly defining the required quality standards and necessary tasks (such as testing, integration, or documentation) to finish an item, the DoD directly informs the Developers' capacity planning. It guides them during Sprint Planning in determining how many Product Backlog items they can realistically select and complete within the Sprint timebox, ensuring they do not overcommit and can deliver a usable Increment.

B. Describe the purpose, objective, and timebox of each Scrum event: The Scrum Guide itself defines the rules, purposes, and timeboxes of Scrum events, not the Definition of Done.
D. Describe the work that must be done before the Sprint can be declared complete: A Sprint is strictly timeboxed and ends when its duration expires, regardless of whether the planned work is completed.

1. Schwaber, K., & Sutherland, J. (2020). The Scrum Guide. Section: Artifacts -> Increment -> Definition of Done, p. 12.

2. Schwaber, K., & Sutherland, J. (2017). The Scrum Guide. Section: Sprint Planning, p. 10 (Contextualizing capacity planning guidance).

The primary accountability of the Product Owner in the Scrum framework is to maximize the value of the product resulting from the work of the Scrum Team. While the Product Owner is responsible for effective Product Backlog management, defining the Product Goal, and engaging with stakeholders, these activities are merely mechanisms to achieve the ultimate objective of value maximization. Value can be measured in various ways depending on the organizational context (e.g., return on investment, customer satisfaction, market share, or social impact), but continuously striving to maximize it remains the core, overarching responsibility of the Product Owner role. Every decision made regarding prioritization and product direction must align with this fundamental goal.

A: Determining release schedules is a tactical activity supporting value delivery, but it is not the ultimate goal or the most important accountability of the role. B: It is practically impossible to meet all stakeholder needs; the Product Owner must prioritize and make trade-offs to maximize overall product value. C: While managing the Product Backlog, the Product Owner is not the sole source of truth; requirements are refined collaboratively with Developers and stakeholders.

- Schwaber, K., & Sutherland, J. (2020). The Scrum Guide. Section: Scrum Team - Product Owner, p. 5.

According to the Scrum Guide, the Scrum Team consists of exactly three accountabilities: the Product Owner, the Scrum Master, and the Developers. Scrum explicitly does not recognize any sub-roles or specialized titles, such as "Tester," regardless of the specific domain or tasks being performed. This ensures a unified focus on the product. Furthermore, quality is not relegated to a single individual or testing phase. The entire Scrum Team shares accountability for creating a valuable, useful Increment every Sprint. While the Developers are specifically accountable for instilling quality by adhering to the Definition of Done, the overarching accountability for the product's value and quality rests collaboratively on the entire Scrum Team, fostering cross-functional teamwork and shared ownership.

A. Incorrect because quality assurance is not isolated to a specific individual finding bugs; it is integrated into the development process by all Developers.
B. Incorrect because Scrum does not recognize a "test manager" role, and reporting metrics to external management contradicts self-management.
C. Incorrect because Developers manage their own work collaboratively; having a separate role to "check" work undermines cross-functional shared accountability.

1. Schwaber, K., & Sutherland, J. (2020). The Scrum Guide. Scrum.org. (Section: Scrum Team, p. 5).

2. Schwaber, K., & Sutherland, J. (2020). The Scrum Guide. Scrum.org. (Section: Developers, p. 5).

During a Sprint, the Product Owner remains actively engaged in maximizing the value of the product. This involves continuously refining and reordering the Product Backlog (Option A) as new insights emerge or market conditions change. The Product Owner must also be available to collaborate with the Developers, answering questions and clarifying the intent of Product Backlog items to ensure the Sprint Goal is met (Option B). Furthermore, the Product Owner continuously interacts with stakeholders to gather feedback, understand their needs, and align future product direction with business objectives (Option E). These activities ensure the Product Backlog remains transparent, visible, and understood.

C: Tracking Sprint progress, such as updating a Sprint burndown chart, is the responsibility of the Developers, not the Product Owner. D: The Developers are self-managing and solely responsible for creating and prioritizing their own tasks within the Sprint Backlog. F: The Daily Scrum is an event specifically for the Developers to inspect progress toward the Sprint Goal; the Product Owner does not run it.

1. Schwaber, K., & Sutherland, J. (2020). The Scrum Guide. Scrum.org. (Section: Product Owner, pp. 5-6).

2. Schwaber, K., & Sutherland, J. (2020). The Scrum Guide. Scrum.org. (Section: Developers, p. 5).

3. Schwaber, K., & Sutherland, J. (2020). The Scrum Guide. Scrum.org. (Section: The Daily Scrum, p. 9).

In complex environments characterized by high uncertainty regarding customer needs, Scrum and Evidence-Based Management (EBM) advocate for a strictly empirical approach to mitigate risk. The most effective strategy is to decrease the size of releases, utilizing smaller batch sizes to deliver value and gather market feedback more frequently. This rapid feedback loop allows the Scrum Team to focus heavily on validating customer needs through actual usage data rather than relying on upfront assumptions. By releasing smaller, incremental updates, the Product Owner can continuously test hypotheses, measure outcomes, and adapt the Product Backlog accordingly, thereby minimizing the financial and strategic risk of building the wrong product.

C. High uncertainty requires validation through experiments, not immediately abandoning the product for a different investment without empirical evidence.
D. Traditional risk management plans are predictive; Scrum manages risk inherently through empiricism, iterative delivery, and continuous validation rather than static planning documents.

1. Schwaber, K., & Sutherland, J. (2020). The Scrum Guide. Section: Scrum Theory (Empiricism).

2. Scrum.org. (2020). The Evidence-Based Management (EBM) Guide. Section: Hypothesis Testing and Experimentation.

In the context of Evidence-Based Management (EBM), Unrealized Value (UV) represents the potential future value that could be realized if the product met the needs of all potential customers. A key component of identifying Unrealized Value is understanding the "satisfaction gap." This gap is defined as the difference between a user's desired outcome (what they are trying to achieve or the problem they want solved) and their actual experience with the current solutions available to them. By measuring and addressing this gap, Product Owners can discover opportunities to innovate, improve the product, and capture more market value, thereby maximizing the product's overall impact and success.

A: Total market size relates to the overall potential customer base and market volume, not the individual user's satisfaction or experience gap. C: Market share indicates the percentage of the market controlled by the product, which is a lagging indicator of Current Value, not the satisfaction gap itself.

1. Scrum.org

"Evidence-Based Management (EBM) Guide" (2020)

Section: Unrealized Value (UV)

p. 5.

2. Scrum.org

"Evidence-Based Management (EBM) Guide" (2020)

Section: Key Value Measures (KVMs)

p. 7.