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

The Product Owner is accountable for ordering the Product Backlog to best achieve goals and missions. While maximizing value (A) is a primary driver, ordering is a complex activity influenced by multiple factors. Dependencies, both internal between Product Backlog Items (B) and external to other products or teams (C), are crucial considerations. Ignoring dependencies can create impediments, delay value delivery, and make the plan unworkable. Therefore, a Product Owner must balance value, risk, effort, and various dependencies to create an effective and logical ordering of the work.

D. The availability of the Scrum Master.

The Scrum Master is a facilitator and coach for the Scrum Team. Their availability does not dictate the sequence of work or the value delivered, and thus is not a criterion for ordering the Product Backlog.

E. All of the above.

This option is incorrect because the availability of the Scrum Master (D) is not a valid criterion for ordering the Product Backlog.

1. Schwaber

K.

& Sutherland

J. (2020). The Scrum Guide. Scrum.org. p. 6. The guide states the Product Owner is accountable for "Ordering Product Backlog items" with the goal of maximizing the value of the product. While it doesn't list all criteria

the concept implies considering all factors necessary for a viable order.

2. Scrum.org. (n.d.). Scrum Glossary. Retrieved from https://www.scrum.org/resources/scrum-glossary. Under the definition for "Product Backlog

" it states

"It is ordered by the Product Owner based on considerations like risk

value

dependencies

and necessity." This directly supports options A and B

with "dependencies" encompassing C.

3. Scrum.org. (n.d.). The Product Owner Role. Scrum.org Learning Path. Retrieved from https://www.scrum.org/pathway/product-owner-learning-path. This resource clarifies that ordering is not just prioritization: "The Product Owner may also take into account risk

dependencies

and other factors when ordering the Product Backlog." This confirms that value

dependencies (internal and external)

and other factors are used.

The Scrum Master acts as a servant-leader for the Scrum Team. Their primary contributions to productivity are not through direct management but through enablement. By facilitating team decisions (B), the Scrum Master empowers the team to self-manage, fostering ownership and improving the quality and speed of their problem-solving. By actively removing impediments (D), the Scrum Master clears the path for the Development Team, eliminating blockers and wasteful delays that hinder their progress. These two functions directly support the team's ability to focus on delivering a high-value Increment and operate at its full potential.

A. Keeping high-value features high in the Product Backlog is the primary responsibility of the Product Owner, who is accountable for maximizing product value.

C. While ensuring events are time-boxed is part of the Scrum Master's role, it is a mechanism of facilitation, not a primary driver of productivity itself compared to removing blockers.

1. Schwaber

K.

& Sutherland

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

Page 7

"Scrum Master" section: "The Scrum Master serves the Scrum Team in several ways

including: ... Causing the removal of impediments to the Scrum Team’s progress." This directly supports option D.

Page 7

"Scrum Master" section: "The Scrum Master serves the Scrum Team in several ways

including: ... Coaching the team members in self-management and cross-functionality." Facilitating decisions (Option B) is a core technique for coaching in self-management.

2. Russo

D.

& Stol

K. J. (2021). Scrum Master's relevance in agile projects: A survey of practitioners. Journal of Systems and Software

173

110883. https://doi.org/10.1016/j.jss.2020.110883

Section 4.1

Table 3: The study identifies "Removing impediments" and "Facilitating meetings" as the two most important activities performed by Scrum Masters according to practitioners

directly supporting options D and B.

The amount of work required for a Product Backlog item is determined by what is necessary to meet the Scrum Team's agreed-upon Definition of Done (DoD). The DoD is a formal, shared understanding of all the work, including testing and integration, required to create a valuable, usable, and potentially releasable Increment. During Sprint Planning, the Developers forecast which items they can complete to this quality standard within the Sprint. An item is not considered complete until it meets every criterion in the DoD. This ensures a consistent level of quality and transparency regarding the state of the work.

A. Deferring work means an item is not "Done." In Scrum, the goal is to deliver a completed, usable Increment, not partial work that carries over.

C. "Some testing" is an insufficient and ambiguous standard. The Definition of Done ensures all necessary quality assurance activities are completed for an item to be considered finished.

D. Scrum does not prescribe a proportional allocation of time. The effort for each activity varies per item and is determined by the Developers, not a fixed formula.

1. Schwaber

K.

& Sutherland

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

Page 9

"Definition of Done" section: "The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product. ... If a Product Backlog item does not meet the Definition of Done

it cannot be released or even presented at the Sprint Review."

Page 8

"Sprint Planning" section: "The Developers are responsible for all quality-adhering work needed to create a Done Increment."

2. Verwijs

C.

& Russo

D. (2022). A Theory of Scrum. Zenodo. https://doi.org/10.5281/zenodo.7264986

Page 11

Section 3.3.3

"Definition of Done": "The Definition of Done is a commitment that creates transparency for the work that is required to create a usable Increment that is 'Done'. It is a shared understanding within the Scrum Team of what it means for work to be complete." This reinforces that "Done" is the measure of completeness.

The Scrum Guide is explicit that a single product has one Product Backlog, which serves as the single source of work. This ensures transparency and alignment across all development efforts. Furthermore, the guide defines the Product Owner as one person, not a committee, who is solely accountable for managing the Product Backlog and maximizing the product's value. When multiple Scrum Teams collaborate on one product, they share the same Product Goal, Product Backlog, and Product Owner. This unified structure is fundamental for maintaining a cohesive product vision and preventing the conflicting priorities that would arise from multiple backlogs or owners.

A. A separate Product Backlog for each team working on one product creates conflicting priorities, integration chaos, and a fragmented product.

D. Having multiple Product Owners for one product diffuses accountability and leads to a disjointed product vision and conflicting directions for the teams.

E. The "Chief Product Owner" is a construct from scaling frameworks, not a core Scrum role. The fundamental principle is one accountable Product Owner per product.

1. Schwaber

K.

& Sutherland

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

On one Product Owner: "The Product Owner is one person

not a committee." (p. 5)

On one Product Backlog: "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." (p. 9)

On multiple teams

one product: "If Scrum Teams become too large

they should consider reorganizing into multiple cohesive Scrum Teams

each focused on the same product. Therefore

they should share the same Product Goal

Product Backlog

and Product Owner." (p. 6)

2. Maximini

D. (2015). The Scrum Culture: Introducing Agile Methods in Organizations. Springer International Publishing.

In the section on "The Product Owner

" the book emphasizes that for a product

there is "exactly one Product Backlog and therefore also exactly one Product Owner" to ensure a single point of decision-making and a clear product vision

even in scaled environments. (Chapter 4

p. 59) DOI: https://doi.org/10.1007/978-3-319-11827-7

The Scrum Master's role is to be a servant-leader who coaches the team and helps remove impediments. When a team cannot complete items to a desired quality standard due to environmental or tooling constraints, the Scrum Master has two primary responsibilities: ensuring transparency and fostering improvement.

First, the team must be transparent about what it can realistically achieve. This is done by establishing a Definition of Done (DoD) that reflects the team's current capabilities and context (D). This ensures everyone understands what "Done" means for any Increment produced.

Second, the Scrum Master must coach the team to address these shortcomings over time (A). This involves helping them identify and acquire the necessary skills, tools, and environmental improvements, thereby enabling the DoD to become more stringent in the future.

B. Refocusing an entire Sprint on the environment instead of delivering an Increment is an extreme measure. Work to improve the environment should be part of the Product Backlog and prioritized accordingly.

C. Accepting partially done work violates the core principle of Scrum, which is to deliver a usable, "Done" Increment. This creates technical debt and reduces transparency.

E. A lack of tools is an impediment to be overcome, not a reason to abandon the Scrum framework. The Scrum Master's role is to help the team navigate such challenges.

1. Schwaber

K.

& Sutherland

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

On the Scrum Master's Role (supports A): "The Scrum Master serves the Scrum Team in several ways

including: Coaching the team members in self-management and cross-functionality; ... Causing the removal of impediments to the Scrum Team’s progress." (p. 6). This directly supports coaching the team to improve its environment.

On the Definition of Done (supports D): "If the Definition of Done for an increment is part of the standards of the organization

all Scrum Teams must follow it as a minimum. If it is not an organizational standard

the Scrum Team must create a Definition of Done appropriate for the product." (p. 9). This supports creating a realistic DoD based on current circumstances.

On Increments (refutes C): "In order to provide value

the Increment must be usable." (p. 9). Partially done work is not usable and therefore does not constitute a valid Increment.

2. Stray

V.

Sjøberg

D. I.

& Dybå

T. (2016). Understanding the Definition of Done: A Case Study in a Small Software Company. In Proceedings of the 10th ACM/IEEE International Symposium on Empirical Software Engineering and Measurement (ESEM '16). Association for Computing Machinery

New York

NY

USA

Article 59

1–10. https://doi.org/10.1145/2961111.2962626

Section 4.1

"The DoD as a Checklist": The paper highlights that the DoD makes quality requirements explicit and creates transparency. It states

"The DoD makes explicit what is required for a PBI to be considered complete... This helps create transparency..." This supports the need for a clear

achievable DoD (D) to ensure transparency about the Increment's state. The paper also discusses the evolution of the DoD

which aligns with the continuous improvement aspect of coaching (A).

The official Scrum Guide states that the Definition of Done (DoD) is the commitment associated with the Increment. If the DoD is not a standard provided by the organization, the Scrum Team must create one that is appropriate for the product. This is a collaborative effort involving all members of the Scrum Team—the Product Owner, the Developers, and the Scrum Master. This collective ownership ensures a shared understanding of the quality and completeness required for an Increment to be considered potentially releasable, which is essential for transparency and building trust.

A. The Scrum Master: The Scrum Master is a coach and facilitator; they ensure the team understands the need for a DoD but do not create it.

C. The Product Owner: The Product Owner contributes to the DoD, ensuring it meets product and stakeholder quality expectations, but does not create it alone.

D. The Developers: The Developers are primary contributors to the technical aspects of the DoD, but it is a shared commitment for the entire Scrum Team.

---

1. Schwaber

K.

& Sutherland

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

Reference: Page 10

Section "Commitment: Definition of Done". The guide states

"If it is not an organizational standard

the Scrum Team must create a Definition of Done appropriate for the product."

2. Verwijs

C.

& Russo

D. (2022). A Theory of Scrum's Five Values. In Proceedings of the 23rd International Conference on Agile Software Development (XP 2022). Association for Computing Machinery

New York

NY

USA

19–35.

Reference: Page 27

Section 4.3. The paper discusses how the DoD is a team-level agreement

stating

"The Definition of Done is a key practice in Scrum to make the quality of the work transparent and is created by the Scrum Team."

DOI: https://doi.org/10.1145/3533716.3533721

3. Schwaber

K.

& Beedle

M. (2002). Agile Software Development with Scrum. Prentice Hall.

Reference: Chapter 7

Page 79. The text explains

"The team is responsible for the Definition of Done. The team agrees on a definition that is workable and that will produce a usable

high-quality increment of product." The term "team" in this context refers to the entire Scrum Team.

The Scrum framework, as defined in the official Scrum Guide, is explicit about the nature of the Product Owner role. The Product Owner is a single individual, not a committee, to ensure there is one person with final authority on the Product Backlog, thereby preventing conflicting priorities and ensuring clear accountability. This single-person accountability is crucial for decisive and effective product management.

One of the primary accountabilities of the Product Owner is effective Product Backlog management. This includes creating, communicating, and, most importantly, ordering Product Backlog Items to best achieve the Product Goal and maximize the value of the work performed by the Developers.

B. The Scrum Guide specifies one Product Owner per Scrum Team to provide a single point of accountability and a unified vision for the product.

C. The Scrum Guide explicitly states, "The Product Owner is one person, not a committee," to avoid the delays and compromises inherent in group decision-making.

1. Schwaber

K.

& Sutherland

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

Page 5

"The Product Owner" section

Paragraph 3: "The Product Owner is one person

not a committee. The Product Owner may represent the needs of many stakeholders in the Product Backlog." This directly supports answer A and refutes B and C.

Page 5

"The Product Owner" section

Paragraph 4: "The Product Owner is also accountable for effective Product Backlog management

which includes: ... Ordering Product Backlog items;" This directly supports answer D.

2. Schwaber

K. (2004). Agile Project Management with Scrum. Microsoft Press.

Chapter 6

"The Product Owner

" pp. 67-68: This chapter details the necessity of the Product Owner being a single

empowered individual responsible for the product's success and for managing the Product Backlog. It reinforces that this role cannot be effectively filled by a committee.

The statement is true. The Scrum Guide, the definitive body of knowledge for Scrum, explicitly defines the Scrum Team as comprising three specific accountabilities: one Product Owner, one Scrum Master, and Developers. These roles are not optional. The absence, lack of engagement, or insufficient availability of the Product Owner or Scrum Master directly impedes the team's ability to function as prescribed by the framework, which negatively affects the value delivered and the overall outcomes of the Sprint.

A. False. A Scrum Master is only required when asked for by the Scrum Team.

This is incorrect. The Scrum Master is a mandatory and accountable role within the Scrum Team, not an optional consultant hired on-demand.

B. True. Each must be 100% dedicated to the Scrum Team.

While the statement is fundamentally true, the reasoning is flawed. The Scrum Guide does not mandate that the Product Owner or Scrum Master be 100% dedicated to a single team.

C. False. A Product Owner can be replaced by a subject matter expert in the Scrum Team.

This is incorrect. The Product Owner is a specific role with the accountability for maximizing product value. A subject matter expert contributes knowledge but does not hold this accountability.

---

1. Schwaber

K.

& Sutherland

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

Page 5

"The Scrum Team": "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." This passage confirms that both roles are required components of every Scrum Team.

Pages 5-7

"Product Owner" and "Scrum Master" sections: These sections detail the specific accountabilities of each role. The descriptions of their responsibilities (e.g.

the PO maximizing product value

the SM ensuring Scrum is enacted) implicitly support the idea that their participation and availability are critical to achieving desired outcomes.

2. Mahnič

V. (2012). What We Have Learned from Applying Scrum to A Dozen Software Projects. Journal of Software

7(9). https://doi.org/10.4304/jswe.7.9.1997-2005

Page 1998

Section II.A

"Scrum Roles": "The Scrum team consists of three roles: the product owner

the team

and the ScrumMaster." This academic source reinforces the official Scrum Guide's definition of the mandatory roles within a Scrum Team.

The Product Owner is accountable for maximizing the value of the product. To effectively fulfill this responsibility, a holistic awareness of multiple domains is essential. This includes understanding the market landscape through competitive research (A), gathering direct input from users via customer feedback (B), setting a clear direction with a compelling product vision (C), and grounding decisions in reality through forecasting and feasibility analysis with the Developers (D). Each of these elements provides critical input for ordering the Product Backlog to optimize value delivery, making all of them necessary for the Product Owner's success.

A, B, C, D: These options are individually correct but incomplete. A Product Owner requires awareness of all these areas, not just one, to effectively maximize product value.

F: This option is incorrect as all the listed items are fundamental aspects of the Product Owner's role and responsibilities as described in the Scrum framework and product management principles.

---

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... The Product Owner may represent the needs of many stakeholders in the Product Backlog." This supports the need for customer feedback

competitive research

and market awareness to determine value.

Page 6: The guide introduces the Product Goal as a long-term objective and a commitment

which is a concrete step toward the overall product vision.

2. Verwijs

C.

& Russo

D. (2022). What Do We Know About the Product Owner? A Systematic Literature Review. In Product-Focused Software Process Improvement (pp. 147-163). Springer

Cham.

Section 4.1

Table 2: This review synthesizes the role of the Product Owner from 61 primary studies. It identifies key activities and knowledge areas including "Vision and Goal Setting

" "Market Research

" and "Stakeholder Management

" which directly correspond to options C

A

and B. Feasibility (D) is an intrinsic part of backlog management in collaboration with the development team.

DOI: https://doi.org/10.1007/978-3-031-21383-810

3. Bass

J. M. (2019). The product owner in large-scale agile: A systematic literature review and an interview study. Information and Software Technology

115

105-121.

Section 4.2: Discusses the PO's responsibility for "product vision and strategy

" which involves understanding the market

competitors

and customer segments to define a valuable product. This covers options A

B

and C.

4. MIT OpenCourseWare. (2016). 15.785 Digital Product Management. Massachusetts Institute of Technology.

Course Syllabus

Session Topics: The course outline covers essential Product Owner competencies such as "Understanding Customer Needs" (relates to B)

"Product Vision & Strategy" (relates to C)

"Competitive Analysis" (relates to A)

and "Agile Development & Roadmapping" (relates to D).

Sprint Planning initiates the Sprint by laying out the work to be performed. The 2020 Scrum Guide explicitly structures this event around three topics, which directly correspond to this answer. First, the team collaborates on a Sprint Goal, addressing "Why" the Sprint is valuable. Second, the Developers select items from the Product Backlog, determining "What" can be done. Third, the Developers create a plan for delivering the selected items into a Done Increment, which answers "How" the work will get done. This comprehensive approach ensures the team has a clear purpose, a selected set of work, and an actionable plan for the Sprint.

A. Who is on the team and what team member roles will be.

This concerns team formation, which happens outside of Sprint Planning. The Scrum Team is expected to be stable throughout the Sprint.

B. How conditions have changed and how the Product Backlog should evolve.

This describes Product Backlog refinement, a continuous activity, not the specific purpose of the Sprint Planning event itself.

C. What to do and who will do it.

While "what to do" is correct, assigning work to specific individuals ("who will do it") during planning undermines the Developers' self-management.

E. What went wrong in the last Sprint and what to do differently this Sprint.

This is the purpose of the Sprint Retrospective, which is focused on inspecting and adapting the team's processes.

1. Schwaber

K.

& Sutherland

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

"Sprint Planning addresses the following topics: Topic One: Why is this Sprint valuable? ... Topic Two: What can be Done this Sprint? ... Topic Three: How will the chosen work get done?" This directly maps to "Why

" "What

" and "How."

2. Verwijs

C.

& Russo

D. (2023). A Theory of Scrum's Law. In Agile Processes in Software Engineering and Extreme Programming – Workshops (pp. 103-112). Springer

Cham. The authors discuss the purpose of Scrum's events

noting that Sprint Planning is for the Scrum Team to "agree on a Sprint Goal (Why)

select the work to achieve it (What)

and create a plan (How)." (Section 3.1

p. 106).

3. Hohl

P.

Klünder

J.

van Bennekum

A.

et al. (2018). Back to the future: why is agile today not what we practiced 10 years ago and what we should practice in the future. In International Conference on Agile Software Development (pp. 125-133). Springer

Cham. The paper reinforces that Sprint Planning involves selecting backlog items and creating a plan to deliver them

covering the "What" and "How" aspects. The commitment to a Sprint Goal provides the "Why." (Section 3).

The Scrum framework is designed around a consistent and predictable rhythm, known as a cadence. Sprints are the heartbeat of this rhythm. According to the Scrum Guide, "A new Sprint starts immediately after the conclusion of the previous Sprint." This continuous cycle of Sprints, without any gaps in between, ensures that the Scrum Team maintains momentum, focus, and a steady pace of delivering value. The conclusion of one Sprint's Retrospective is immediately followed by the next Sprint's Planning event, creating a seamless flow.

A. Waiting for customer acceptance testing introduces a delay and a waterfall-style phase gate, which is contrary to the iterative nature of Scrum.

B. Relying on external approval from an architect creates a dependency that undermines the Scrum Team's self-management and autonomy, causing unnecessary delays.

D. The selection of Product Backlog items occurs during Sprint Planning, which is the very first event within a new Sprint, not a prerequisite for starting it.

1. Schwaber

K.

& Sutherland

J. (2020). The Scrum Guide. Scrum.org. p. 8. "Sprints are the heartbeat of Scrum

where ideas are turned into value. They are fixed length events of one month or less to create consistency. A new Sprint starts immediately after the conclusion of the previous Sprint."

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. While focused on the Daily Scrum

this study discusses the importance of rhythm and routine in Agile practices (p. 119)

which is established by the unwavering

back-to-back cadence of Sprints.

3. MIT Sloan School of Management. (2016). 15.S63: Advanced Management & Leadership - Session 3: Agile at Scale. MIT OpenCourseWare. The course materials illustrate the Scrum process as a continuous cycle

where the output of one Sprint (Retrospective) flows directly into the input of the next (Sprint Planning)

reinforcing the principle of immediate succession.

The Scrum framework emphasizes the value of stable, long-lived teams. A consistent team composition allows members to build trust, develop effective communication patterns, and optimize their collaborative processes, leading to higher performance over time (as described by models like Tuckman's stages of group development). However, the framework is pragmatic. Changes in personnel are sometimes unavoidable. The most effective approach is to make changes only when necessary ("as needed") while acknowledging the predictable, short-term negative impact on productivity. This disruption occurs as the team adjusts its dynamics and integrates the new member(s). This aligns with Scrum's core principle of empiricism and transparency.

A. Changing the team every Sprint would create constant disruption, preventing the team from ever moving beyond the initial "forming" and "storming" stages, thus severely hindering productivity.

B. Ignoring the productivity impact of a team change is unrealistic and violates the Scrum value of transparency. The team's capacity and forecast will be affected.

C. The stance "never" is too rigid and impractical for any real-world organization where personnel changes are a fact of life due to attrition, promotions, or other factors.

1. The Scrum Guide (2020) by Ken Schwaber and Jeff Sutherland.

Reference: Page 5

"The Scrum Team" section. The guide defines the Scrum Team as a "cohesive unit of professionals." Frequent changes disrupt this cohesion

which is the foundation of a self-managing and effective team. While not explicitly stating "productivity reduction

" the emphasis on cohesion implies it.

2. Takeuchi

H.

& Nonaka

I. (1986). The New New Product Development Game. Harvard Business Review

64(1)

137-146.

Reference: Section "Built-in Instability". This foundational article for Scrum highlights that while the project is challenging

the project team itself should be "kept stable throughout." Stability is presented as a key condition for success.

3. Moe

N. B.

Dingsøyr

T.

& Dybå

T. (2010). A teamwork model for understanding an agile team: A case study of a Scrum project. Information and Software Technology

52(5)

480-491.

Reference: Section 4.2

"Team stability". The study notes that "team stability is important for team performance" and that changes in team composition can cause the team to revert to earlier

less productive stages of development. (DOI: https://doi.org/10.1016/j.infsof.2009.11.004)

The Scrum Master is accountable for ensuring Scrum is understood and enacted correctly within the organization. The IT manager's request for a traditional status report indicates a misunderstanding of how progress is made transparent in Scrum. The Scrum Master's most effective action is to coach the manager, explaining that empirical progress is demonstrated by inspecting a tangible, "Done" Increment during the Sprint Review. This addresses the root cause of the request, educates the stakeholder, and protects the team from wasteful interruptions that do not contribute to the Sprint Goal, thereby upholding Scrum principles.

A. Tell the Developers to fit the report into the Sprint Backlog.

This treats a non-value-adding interruption as legitimate work, distracting the Developers from their primary focus of creating a valuable Increment and achieving the Sprint Goal.

B. Ask the Product Owner to send the manager the report.

This merely shifts the wasteful task to another team member and fails to address the manager's fundamental misunderstanding of Scrum's empirical nature.

C. Create and deliver the report to the manager herself.

This positions the Scrum Master as an administrative assistant rather than a coach and leader, reinforcing outdated practices and preventing the organization from properly adopting Scrum.

D. Tell the Scrum Team to figure it out themselves.

This is an abdication of the Scrum Master's responsibility to remove impediments and coach the organization, especially when the issue stems from a stakeholder external to the team.

1. Schwaber

K.

& Sutherland

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

Page 7

"Scrum Master": "The Scrum Master serves the organization in several ways

including: Leading

training

and coaching the organization in its Scrum adoption; ... Helping employees and stakeholders understand and enact an empirical approach for complex work". This directly supports coaching the IT manager (Option E).

Page 10

"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." This identifies the correct forum for stakeholders to understand progress.

2. Verwijs

C.

Russo

D.

& Gorschek

T. (2022). The role of the Scrum Master: a systematic literature review. PeerJ Computer Science

8

e1087.

Section "Identified activities"

Table 2: The paper identifies "Protecting the team" (including shielding from external interferences) and "Teaching

Mentoring

and Coaching" (including coaching stakeholders) as core Scrum Master activities. Option E is a direct application of these responsibilities

whereas options A

B

and C are contrary to them. (https://doi.org/10.7717/peerj-cs.1087)

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 create transparency. By ensuring that all Developers adhere to the DoD, the Product Owner and all stakeholders have a clear, shared understanding of what work was completed during the Sprint. This transparency is essential for effective inspection of the Increment at the Sprint Review, which in turn allows for adaptation of the Product Backlog and informed decision-making about the product's future direction and potential release.

A. While a consistent DoD can lead to more predictable delivery and help in forecasting, its primary purpose is ensuring a transparent and shared understanding of the Increment's quality and completeness.

C. The DoD applies to the quality of the Increment within a single Sprint; it does not serve as a tool for guaranteeing deliverables over multiple future Sprints, as the Product Backlog is emergent.

D. This describes a dysfunctional, command-and-control behavior. Scrum operates on trust and collaboration, not reprimand. Velocity is a planning tool for the Developers, not a performance metric for management.

---

1. Schwaber

K.

& Sutherland

J. (2020). The Scrum Guide. Scrum.org. p. 9. "The Definition of Done creates transparency by providing everyone a shared understanding of what work was completed as part of the Increment. If a Product Backlog item does not meet the Definition of Done

it cannot be released or even presented at the Sprint Review."

2. Ceschi

M.

Sillitti

A.

& Succi

G. (2019). The Definition of Done: A Reference for Practitioners and Researchers. In Agile Processes in Software Engineering and Extreme Programming – Workshops (pp. 279-286). Springer

Cham. DOI: https://doi.org/10.1007/978-3-030-30126-233. The paper states

"The DoD is a key element to ensure transparency and a common understanding of the quality of the delivered increment among all the stakeholders." (Section 2

Paragraph 1).

3. University of Virginia Darden School of Business. (n.d.). Agile Development in Practice. Coursera. In Module 1

"Getting Started with Agile

" the course materials emphasize that artifacts like the Definition of Done are designed to maximize transparency

which is a pillar of the empirical process control theory upon which Scrum is founded.

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)

The Scrum framework operates on a consistent and predictable cadence. Sprints are consecutive, fixed-length events that form the heartbeat of Scrum. To maintain this rhythm and avoid creating gaps in the development process, a new Sprint begins immediately after the previous Sprint concludes. The conclusion of a Sprint is marked by the Sprint Retrospective, and the start of the next is marked by Sprint Planning. This continuous cycle ensures a steady flow of value delivery and provides a regular opportunity for inspection and adaptation.

A. Sprints are not tied to specific calendar days like Monday. The cadence is continuous, regardless of the day of the week.

C. Sprint Planning is the very first event within a Sprint. Therefore, the Sprint must have already started for Sprint Planning to occur.

D. The start of a Sprint is dictated by the Scrum framework's cadence, not an individual's readiness, to ensure predictability and rhythm.

---

1. Schwaber

K.

& Sutherland

J. (2020). The Scrum Guide. Scrum.org. p. 8. "Sprints are the heartbeat of Scrum

where ideas are turned into value. They are fixed length events of one month or less to create consistency. A new Sprint starts immediately after the conclusion of the previous Sprint."

2. Sutherland

J.

& Sutherland

J. J. (2014). Scrum: The Art of Doing Twice the Work in Half the Time. Crown Business. In Chapter 4

"Time

" the authors emphasize the importance of a regular

uninterrupted rhythm

stating

"Once you decide how long a Sprint should be

that’s it. It never changes... At the end of the Sprint

the team shows what they’ve built... The next day they start the next Sprint."

3. Stellman

A.

& Greene

J. (2014). Learning Agile: Understanding Scrum

XP

Lean

and Kanban. O'Reilly Media. In Chapter 11

"Scrum

" the Sprint cycle is described as continuous: "When one sprint ends

the next sprint begins." This reinforces the concept of no downtime between Sprints.

The Product Owner is accountable for maximizing the value of the product. Value is an outcome determined by the customer and user, not an internal measure of output. To ensure the product delivers value, the Product Owner must focus on evidence-based measures.

Feature usage (A) provides quantitative data on which parts of the product customers find useful.

Direct customer feedback (B) offers qualitative insights into user satisfaction, pain points, and needs.

Ease of adoption and use (C) directly impacts the customer's ability to realize the product's value.

These three elements provide a holistic view of the product's current value and guide the Product Owner in making decisions to enhance it.

D. Velocity is an internal team metric measuring output per Sprint, not the value or outcome delivered to the customer.

E. Scrum is founded on empiricism and adapting to change. Minimizing scope changes prevents the team from responding to new insights to maximize value.

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 necessitates a focus on value-centric measures

not internal metrics.

2. Scrum.org. (2020). The Evidence-Based Management Guide. pp. 6-8. This guide details Key Value Areas (KVAs) for measuring value. "Current Value" (CV) is a key KVA that is assessed through metrics like customer satisfaction

employee satisfaction

and customer usage index

which directly support options A

B

and C.

3. Maximini

D. (2015). The Scrum Culture: Introducing Agile Methods in Organizations. Springer International Publishing. p. 61. In the chapter on the Product Owner

it is emphasized that "The Product Owner is responsible for the value of the product... He is not responsible for the velocity of the team." This distinguishes the PO's focus on value (outcome) from team productivity (output). DOI: https://doi.org/10.1007/978-3-319-11827-7

The core principle at play is self-management. The Scrum Guide mandates that Scrum Teams are self-managing, meaning they determine how to best accomplish their work. The logistical arrangements for the Daily Scrum, an event owned by the Developers, fall squarely within this domain. The Scrum Master's role is to be a servant-leader who coaches the team in self-management and Scrum principles. Intervening by providing a solution or escalating the issue would undermine the team's autonomy and accountability. The most appropriate action is to empower the Developers to identify and implement their own solution, thereby strengthening their self-management capabilities.

B. Ask the Developers to alternate who is responsible for meeting setup.

This is a prescriptive solution. The Scrum Master should not dictate how the team solves its problems, as this undermines their self-management and ownership.

C. Set up the meeting and tell the Scrum Team that is how it will be done.

This is a command-and-control anti-pattern. It removes responsibility from the team and positions the Scrum Master as an administrator or manager, which contradicts their true role.

D. Inform management and ask them to solve it.

This is an inappropriate escalation. The team is fully capable of resolving this internal logistical issue. Escalating it disempowers the team and misrepresents the issue as an impediment they cannot solve.

1. Schwaber

K.

& Sutherland

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

Page 5

"Scrum Team" section: "Scrum Teams are self-managing

meaning they internally decide who does what

when

and how." This directly supports allowing the team to solve their own logistical problems.

Page 7

"Scrum Master" section: "The Scrum Master serves the Scrum Team in several ways

including: Coaching the team members in self-management and cross-functionality;" This defines the Scrum Master's coaching role rather than a directive one.

Page 9

"Daily Scrum" section: "The Daily Scrum is a 15-minute event for the Developers of the Scrum Team." This establishes the Developers' ownership of the event and

by extension

its logistics.

The Scrum framework is founded on the principle of self-management. The Developers are accountable for all aspects of creating a usable Increment each Sprint. This includes creating the plan for the Sprint (the Sprint Backlog) and tracking their own progress toward the Sprint Goal. The Daily Scrum is a key event specifically for the Developers to inspect progress and adapt their plan for the next 24 hours. This direct, daily management of their work ensures focus and adaptability, making them solely accountable for managing their progress within the Sprint.

B. Scrum does not recognize hierarchies like "junior" or "senior" within the Developers; the entire group is collectively accountable.

C. The Scrum Master is a facilitator and coach who ensures the team adheres to Scrum principles, but they do not manage the team's work.

D. The Product Owner is accountable for maximizing product value by managing the Product Backlog, not for managing the Developers' daily progress.

---

1. Schwaber

K.

& Sutherland

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

Page 6

"Developers" section: "The Developers are always accountable for: Creating a plan for the Sprint

the Sprint Backlog; ... Adapting their plan each day toward the Sprint Goal; and

Holding each other accountable as professionals."

Page 9

"Daily Scrum" section: "The Daily Scrum is a 15-minute event for the Developers of the Scrum Team... 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 creates focus and improves self-management."

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

"Planning the day": The study identifies that the daily meeting is a core mechanism for the team to synchronize and manage its own work. It states

"The main purpose of the daily stand-up meeting is for the team members to coordinate their work for the next 24 h." This reinforces that the team (Developers) manages its own progress.

The Daily Scrum is a 15-minute event specifically for the Developers of the Scrum Team. Its purpose is to inspect progress toward the Sprint Goal and adapt the Sprint Backlog for the upcoming day's work. According to the Scrum Guide, the Product Owner's participation is only required if they are also actively working on items in the Sprint Backlog. In this scenario, they are not participating as a Product Owner but as a Developer, contributing to the daily plan alongside the other Developers. Their input on the work they are performing is crucial for the team's synchronization.

A. The Scrum Master is a facilitator and coach; they do not have the authority to mandate the Product Owner's attendance at the Developers' event.

C. While impediments may be identified during the Daily Scrum, it is not a problem-solving meeting. The necessary conversations to resolve them typically happen after the Daily Scrum.

D. The Daily Scrum is a tactical planning event for Developers. Representing the stakeholder's view is a continuous activity for the Product Owner, not one specifically tied to this meeting.

1. Schwaber

K.

& Sutherland

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

"Daily Scrum" section

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

2. Rubin

K. S. (2012). Essential Scrum: A Practical Guide to the Most Popular Agile Process. Addison-Wesley Professional. In Chapter 17

"The Daily Scrum

" it is clarified that the event is for the Development Team (now called Developers) to synchronize their work. Others may attend but only team members participate. This reinforces that participation is tied to being part of the team performing the work.