PSPO-I Practice Questions

Scrum is founded on empiricism, which emphasizes making decisions based on observation and feedback. Customer satisfaction is a critical measure of the value delivered. To effectively inspect and adapt the product, feedback loops must be short. The Scrum framework facilitates this through events like the Sprint Review, which occurs at least once per month. Measuring customer satisfaction frequently allows the Product Owner and the Scrum Team to validate hypotheses, understand if they are delivering value, and adjust the Product Backlog accordingly. This aligns with the agile principle of continuous improvement and maximizing the value of the product resulting from development.

B. Quarterly: This cadence is too infrequent for a Scrum environment, where Sprints are one month or less. It would introduce significant delays in receiving crucial feedback for adaptation.

C. Daily: While some metrics might be gathered daily (e.g., usage data), measuring overall satisfaction this often is typically impractical, can lead to survey fatigue, and is not a prescribed practice.

D. Annually: This timeframe is completely contrary to the principles of agility and empiricism. An annual feedback loop makes timely inspection and adaptation impossible.

1. Schwaber

K.

& Sutherland

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

Page 3

"Scrum Theory": "Scrum is founded on empiricism and lean thinking. Empiricism asserts that knowledge comes from experience and making decisions based on what is observed." Frequent measurement is a prerequisite for observation.

Page 9

"Sprint Review": "The purpose of the Sprint Review is to inspect the outcome of the Sprint and determine future adaptations... This is an informal meeting

not a status meeting

and the intended outcome is feedback and a revised Product Backlog..." This event happens at the end of every Sprint

creating a frequent feedback opportunity.

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

Page 6

"Measuring Value": "Organizations need to inspect their EBM measures frequently. The appropriate frequency depends on the measure and the context of the organization

but is often between daily and quarterly." This supports "Frequently" as the best general principle

as it encompasses the need for regular inspection without being overly prescriptive.

Page 8

"Current Value": This section lists "Customer Satisfaction" as a key example of a measure that indicates the value the product delivers to customers today. Frequent monitoring is implied to understand current market reception.

The 2020 Scrum Guide explicitly states, "The entire Scrum Team is accountable for creating a valuable, useful Increment every Sprint." This is a fundamental principle of the framework. The Scrum Team, consisting of the Product Owner, the Scrum Master, and the Developers, is a cohesive, self-managing unit. Their collective accountability ensures a shared focus on delivering a usable and potentially releasable product enhancement during each Sprint. This outcome, the Increment, is the primary measure of progress and a concrete step toward achieving the Product Goal.

B. False: This is incorrect. The Scrum Guide, the definitive source for Scrum, unambiguously assigns this accountability to the Scrum Team as a whole. Denying this statement contradicts a core tenet of the framework.

1. Schwaber

K.

& Sutherland

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

"The Scrum Team" section

Paragraph 1.

2. Schwaber

K.

& Sutherland

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

"Artifacts: Increment" section

Paragraph 1.

3. Hayes

W. (2022

August 2). The Scrum Team: Who Does What? Carnegie Mellon University Software Engineering Institute (SEI) Insights. Retrieved from https://insights.sei.cmu.edu/blog/the-scrum-team-who-does-what/. The article reiterates

"The entire Scrum Team is accountable for creating a valuable

useful Increment every Sprint."

The Daily Scrum is a key inspection and adaptation event for the Developers of the Scrum Team. Its primary purpose is to inspect progress toward the Sprint Goal and to create a plan for the next 24 hours of work. This involves improving communication and promoting quick decision-making. A critical part of this process is identifying any impediments that are blocking progress, which allows the team to address them promptly (D). The outcome of this inspection and planning is a shared understanding among the Developers of the most crucial work to tackle next, ensuring they are aligned and can make the best possible progress toward the Sprint Goal (E).

A. The Daily Scrum is a planning event for the Developers, not a status update for the Scrum Master to plan their work.

B. While the Scrum board is updated, the event's purpose is internal team alignment, not creating a transparency artifact for external stakeholders.

C. The Daily Scrum is a collaborative planning meeting for the team, not an individual status report for upper management.

1. Schwaber

K.

& Sutherland

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

Page 10

"Daily Scrum" section: "The purpose of the Daily Scrum is to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary

adjusting the upcoming planned work." This directly supports option E.

Page 10

"Daily Scrum" section: "The Daily Scrum improves communications

identifies impediments

promotes quick decision-making

and consequently eliminates the need for other meetings." This directly supports option D.

Page 10

"Daily Scrum" section: "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." This refutes the idea that it's a status meeting for others (A

C).

As a Scrum Team matures, it embodies the principle of continuous improvement. The Definition of Done (DoD) is a living artifact that represents the team's shared understanding of the quality required for a Product Increment to be releasable. A mature team continuously seeks to improve its processes and the quality of its output. Therefore, it is expected that they will refine and expand their DoD to include more stringent criteria, such as more comprehensive testing, higher performance standards, or improved documentation. This evolution reflects the team's growing capability and commitment to delivering a high-quality product, which is a hallmark of maturity in Scrum.

A. The Sprint Retrospectives will grow to be longer than 4 hours.

The Scrum Guide timeboxes this event (max 3 hours for a one-month Sprint). A mature team should become more efficient, not require longer meetings.

C. A Scrum Master is no longer needed since they are a mature team now.

The Scrum Master's role evolves to focus on larger organizational impediments, but the accountability remains crucial for fostering the Scrum environment and continuous improvement.

D. There will be no need for a timeboxed Sprint.

The timeboxed Sprint is the core of Scrum, providing a consistent cadence for inspection and adaptation. Removing it would dismantle the framework.

E. Sprint Reviews will no longer be needed.

The Sprint Review is a critical feedback event with stakeholders. A mature team would aim to make this event more valuable, not eliminate it.

1. Schwaber

K.

& Sutherland

J. (2020). The Scrum Guide. Scrum.org. In the section "Commitment: Definition of Done

" it is explicitly stated: "As Scrum Teams mature

it is expected that their Definitions of Done will expand to include more stringent criteria for higher quality."

2. Hohl

P.

et al. (2018). The Professional Product Owner: Leveraging Scrum as a Competitive Advantage. Addison-Wesley Professional. Chapter 7

"Quality

" discusses how the Definition of Done is a key lever for quality and that mature teams continuously raise the bar by strengthening it.

3. Birkman

L.

& Walker

A. (2019). Maturing Your Scrum Practice. In 2019 IEEE International Conference on Engineering

Technology and Innovation (ICE/ITMC) (pp. 1-8). IEEE. https://doi.org/10.1109/ICE.2019.8792631. This paper discusses the evolution of Scrum practices in mature teams

noting that refining artifacts like the Definition of Done is a key indicator of maturity.

The Daily Scrum is a 15-minute event specifically for the Developers of the Scrum Team. The primary purpose of this event is for the Developers to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary, adjusting the upcoming planned work. While other members of the Scrum Team, like the Product Owner and Scrum Master, may attend if invited by the Developers, their presence is not mandatory. The event is owned by the Developers to plan their work for the next 24 hours, making their attendance the only mandatory requirement for the event to be effective and serve its purpose as defined in the Scrum framework.

A. The Daily Scrum is not for the Product Owner or Scrum Master; their attendance is optional and not required.

B. The Scrum Master ensures the event occurs but is not a required participant; the event is for the Developers.

D. The Product Owner's attendance is not mandatory. The event is for the Developers to synchronize and plan.

E. The Scrum Team includes the Product Owner and Scrum Master, whose attendance is not mandatory, making this option incorrect.

1. Schwaber

K.

& Sutherland

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

"The Daily Scrum is a 15-minute event for the Developers of the Scrum Team... If the Product Owner or Scrum Master are actively working on items in the Sprint Backlog

they participate as Developers." This clarifies that only Developers are the required attendees in their capacity as Developers.

2. Stray

V.

Sjøberg

D. I.

& Dybå

T. (2016). The daily stand-up meeting: A grounded theory study. Journal of Systems and Software

114

101-124. https://doi.org/10.1016/j.jss.2016.01.004. In their analysis (Section 4.1.1)

the study identifies the core participants as the "team members" (i.e.

the Developers) who are performing the development work

reinforcing that the meeting is primarily for this group to coordinate their activities.

3. MIT OpenCourseWare. (2016). 6.170 Software Studio

Lecture 2: Agile and Scrum. Massachusetts Institute of Technology. The course materials describe the Daily Scrum as a meeting for the development team to synchronize

consistent with the Scrum Guide's definition of required participants being the Developers.

The Sprint Backlog is a living artifact that represents the Developers' real-time plan for achieving the Sprint Goal. It is not static; it emerges and is updated throughout the Sprint as the Developers learn more about the work required. To maintain transparency and ensure the plan is accurate, any newly identified tasks or the further decomposition of existing work should be reflected in the Sprint Backlog as soon as it is discovered. This continuous adaptation is fundamental to Scrum's empirical nature and is the responsibility of the Developers.

A. During the Daily Scrum after the Developers approve it.

While the Sprint Backlog is often adapted during the Daily Scrum, this is not the only time. Updates can and should happen whenever new information emerges.

B. When the Scrum Master has time to enter it.

The Developers own and manage the Sprint Backlog. The Scrum Master is a facilitator, not an administrator responsible for backlog entries.

C. When the Product Owner identifies new work.

The Product Owner manages the Product Backlog, not the Sprint Backlog. The Developers pull work into the Sprint and are solely responsible for managing their plan.

---

1. Schwaber

K.

& Sutherland

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

Page 9

"Sprint Backlog": "The Sprint Backlog is updated throughout the Sprint as more is learned. It should have enough detail that they can inspect their progress in the Daily Scrum." This supports the continuous nature of updates ("as soon as possible") rather than limiting them to a specific event.

Page 6

"Developers": The guide states that Developers are responsible for "Creating a plan for the Sprint

the Sprint Backlog". This confirms their ownership

invalidating options B and C.

2. Stray

V.

Sjøberg

D. I.

& Dybå

T. (2016). The daily stand-up meeting: A grounded theory study. Journal of Systems and Software

114

101-124. https://doi.org/10.1016/j.jss.2016.01.004

Section 4.1.2

Page 108: The study notes that while the Daily Scrum is a key synchronization point

"the plan (Sprint Backlog) was often updated continuously throughout the day as team members finished one task and started on a new one." This academic research confirms that updates are not confined to the meeting itself.

The Sprint Backlog is a forecast by the Developers about what functionality will be in the next Increment. It is not a fixed commitment. When the Developers realize they cannot complete all the selected work, they must act with transparency and collaboration. The correct action is to immediately work with the Product Owner to renegotiate the scope of the Sprint Backlog. This allows for a joint decision on which Product Backlog Items are least critical to achieving the Sprint Goal and can be moved out of the current Sprint. This upholds the Scrum values of focus, commitment (to the Sprint Goal), and openness, ensuring the team adapts to new information as soon as it emerges.

A. Handing off work disrupts the other team's Sprint and avoids addressing the forecasting issue within the original team. Each team is responsible for its own Sprint Backlog.

C. Waiting until the Sprint Review is too late. It violates the principle of transparency and prevents the team from adapting within the Sprint to maximize the value delivered.

D. Reducing the Definition of Done compromises quality, which is non-negotiable. It creates technical debt and results in an Increment that is not potentially releasable.

---

1. Schwaber

K.

& Sutherland

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

Page 9

"Sprint Backlog" section: "If the work turns out to be different than they expected

they collaborate with the Product Owner to negotiate the scope of the Sprint Backlog within the Sprint without affecting the Sprint Goal." This directly supports answer B.

Page 7

"Developers" section: The Developers are accountable for "instilling quality by adhering to a Definition of Done." This directly refutes answer D.

2. Stray

V.

& Moe

N. B. (2020). Understanding coordination in a large-scale agile project. International Conference on Agile Software Development. Springer

Cham. (DOI: https://doi.org/10.1007/978-3-030-49392-91)

This publication discusses inter-team dependencies and coordination. While not a direct quote

the principles outlined emphasize that simply handing off work (as in option A) is an anti-pattern that ignores proper dependency management and team autonomy. Each team plans and manages its own work.

3. Hohl

P.

Klünder

J.

van der Vliet

H.

& Gorschek

T. (2018). A survey of stakeholders’ perspectives on the definition of done in agile software development. In Product-Focused Software Process Improvement (pp. 3-19). Springer

Cham. (DOI: https://doi.org/10.1007/978-3-030-03673-71)

This research emphasizes the Definition of Done as a crucial quality assurance mechanism. The findings support the conclusion that altering it to meet scope (Option D) undermines the integrity and value of the software development process.

The fundamental purpose of every Sprint, including the first, is to deliver a tangible outcome. The Scrum Guide mandates that "the entire Scrum Team is accountable for creating a valuable, useful Increment every Sprint." This means the team must produce a "Done," usable version of the product, even if it's a very small slice. To create this Increment (E), the team must build some form of valuable functionality (D). This approach allows the team to test its processes, validate assumptions, and provide stakeholders with a concrete product to inspect and adapt from the very beginning, embodying the empirical nature of Scrum.

A. Scrum is an empirical framework that avoids detailed, long-term upfront planning. The plan evolves as more is learned.

B. Defining all major features and architecture upfront is a "Big Design Up Front" (BDUF) anti-pattern, contrary to Scrum's emergent approach.

C. This describes a "Sprint 0" anti-pattern. Requirements for future Sprints are refined on a just-in-time basis, not all at once in the first Sprint.

---

1. Schwaber

K.

& Sutherland

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

Page 8

"The Sprint" section: "Sprints are the heartbeat of Scrum

where ideas are turned into value... The entire Scrum Team is accountable for creating a valuable

useful Increment every Sprint." This directly supports options D and E as the core purpose of any Sprint.

Page 11

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

the Increment must be usable." This reinforces that the outcome of the Sprint's work must be a valuable and useful product.

2. Stray

V.

& Moe

N. B. (2020). Understanding coordination in global software engineering: A mixed-methods study on the use of sprints and releases. IET Software

14(2)

133-142. https://doi.org/10.1049/iet-sen.2019.0079

Section 2.1

"Scrum": The paper reiterates the Scrum Guide's principle

stating

"The main goal of a sprint is to produce a ‘done’

usable

and potentially releasable product increment." This supports the creation of a valuable Increment from the first Sprint onward.

The Product Goal, a commitment for the Product Backlog, describes a future state of the product that serves as a long-term objective for the Scrum Team. A clearly defined Product Goal provides a strategic context and direction, ensuring that each Sprint is a deliberate step toward a larger objective rather than an isolated effort (C). It acts as a crucial focusing mechanism, allowing the team to prioritize work and make decisions by constantly evaluating if they contribute to this goal (D). During the Sprint Review, the Product Goal is the benchmark against which the increment and overall progress are inspected, facilitating a more meaningful discussion with stakeholders about future steps (E).

A. The Product Backlog is emergent and never considered "complete." The Product Goal provides a target, not a mechanism for estimating a completion date for an ever-evolving backlog.

B. The Product Goal is a mandatory commitment in Scrum as per the 2020 Scrum Guide. It provides the significant advantages of focus, direction, and a basis for inspection.

1. Schwaber

K.

& Sutherland

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

Page 6: "The Product Goal describes a future state of the product which can serve as a target for the Scrum Team to plan against. The Product Goal is in the Product Backlog... The Product Goal is the long-term objective for the Scrum Team." (Supports C and D).

Page 10: In the section on the Sprint Review

it states

"...progress toward the Product Goal is discussed." (Supports E).

Page 6: "The Product Backlog is an emergent

ordered list of what is needed to improve the product." (Refutes A).

Page 6: "The Product Goal is the commitment for the Product Backlog." (Refutes B).

Scrum does not use a traditional, static project plan. Instead, the Product Backlog serves as the single, authoritative plan for the product. It is an emergent and dynamic artifact that evolves throughout the product's lifecycle. The Product Owner is responsible for managing this backlog, which involves continuously updating and re-ordering it as new information, market feedback, and stakeholder insights become available. This ensures the plan always reflects the most current understanding of what is needed to maximize the product's value.

A. The Product Owner prepares the Product Backlog for Sprint Planning, but the Developers determine how much work they can take on; the PO does not dictate a plan for the Sprint's volume.

C. The Daily Scrum is a planning event for the Developers to inspect progress toward the Sprint Goal. It is not a designated time for the Product Owner to update the overall product plan.

D. The Sprint Retrospective is focused on inspecting the Scrum Team's process and effectiveness, not on updating the Product Backlog or product plan.

1. Schwaber

K.

& Sutherland

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

Page 11

"Product Backlog" section: "The Product Backlog is an emergent

ordered list of what is needed to improve the product. It is the single source of work undertaken by the Scrum Team." This establishes the Product Backlog as the plan.

Page 12

"Product Backlog" section: "The Product Backlog is a living artifact... Product Backlog refinement is the act of breaking down and further defining Product Backlog items into smaller more precise items. This is an ongoing activity to add details

such as a description

order

and size." This confirms its continuous

emergent nature.

2. Hohl

P.

Klünder

J.

van Bennekum

A.

et al. (2018). Backlog Refinement in Large-Scale Agile System Development. In: Product-Focused Software Process Improvement. PROFES 2018. Lecture Notes in Computer Science

vol 11271. Springer

Cham.

Page 1

Abstract: "The product backlog is the central planning artifact in Scrum..." This academic source confirms the role of the Product Backlog as the primary plan in the Scrum framework. (DOI: https://doi.org/10.1007/978-3-030-03673-723)