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

The Product Owner is the single person accountable for effective Product Backlog management, which explicitly includes ordering the items to best achieve goals and missions. This ordering is a continuous process based on value, risk, and dependencies.

Furthermore, the Product Backlog is a key artifact for transparency, one of the three pillars of Scrum. It must be visible to the entire Scrum Team and relevant stakeholders to enable inspection, adaptation, and collaboration. This shared understanding of the upcoming work is crucial for alignment and for making informed decisions about the product's future.

C. All Product Backlog items must be expressed as user stories.

The Scrum Guide is not prescriptive about the format of Product Backlog Items; user stories are a popular practice but not a mandatory rule.

D. All Product Backlog items must be identified before the first Sprint begins.

The Product Backlog is emergent and evolves throughout the product's life. It is never considered complete, which is a core tenet of empiricism.

E. Only the Product Owner can place items on the Product Backlog.

While the Product Owner is accountable for the Product Backlog, they may delegate the work of adding items, and anyone can suggest items for inclusion.

F. The Product Backlog represents the input of all stakeholders and eliminates any need for the Developers to speak to stakeholders.

This statement promotes a communication anti-pattern. Scrum encourages direct collaboration between Developers and stakeholders, particularly during events like the Sprint Review.

1. Schwaber

K.

& Sutherland

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

For A & E: Page 6

"The Product Owner" section states

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

which includes: ... Ordering Product Backlog items... The Product Owner may do the above work or may delegate the responsibility to others. Regardless

the Product Owner remains accountable."

For B & F: Page 9

"Scrum Artifacts" and "Transparency" sections. The guide emphasizes that artifacts must be transparent to enable inspection. The Sprint Review section (Page 11) explicitly details collaboration between the Scrum Team and stakeholders.

For D: Page 9

"Product Backlog" section describes it as "an emergent

ordered list."

2. Paasivaara

M.

Durasiewicz

S.

& Lassenius

C. (2008). Using Scrum in a globally distributed project: a case study. Software Process: Improvement and Practice

13(6)

527-544. https://doi.org/10.1002/spip.402

For A & B: Page 531

Section 3.2

"The product owner was responsible for prioritizing the product backlog... The product backlog was maintained in an Excel sheet on a shared workspace

which was available to all team members." This supports the PO's responsibility for ordering (prioritizing) and the visibility/availability of the backlog.

Personas are a powerful tool for a Product Owner, extending beyond just user needs. They are rich, narrative archetypes that represent key user segments. Their primary function is to build empathy and a deep, shared understanding of user goals, behaviors, and needs (A). This understanding is the foundation for formulating testable hypotheses about what product capabilities will deliver the most value (B). By creating personas for different market segments, teams can better analyze and understand the overall market potential (C). Furthermore, the detailed context within a persona—their motivations, frustrations, and goals—provides critical insights into the key triggers that influence their adoption and purchasing decisions (D). Therefore, personas serve all these strategic functions in product management.

This question asks for the best answer, and since options A, B, C, and D are all valid and interconnected benefits of using personas, selecting any single option would be incomplete. The most comprehensive and therefore best answer is E.

1. Cooper

A.

Reimann

R.

Cronin

D.

& Noessel

C. (2014). About Face: The Essentials of Interaction Design (4th ed.). Wiley.

Reference: Chapter 3

"Modeling Users: Personas and Goals

" pp. 55-78. This foundational text explains that personas are created to understand user goals and needs (supporting A) and to serve as the main characters in design scenarios

which helps in formulating and testing value propositions (supporting B).

2. Gothelf

J.

& Seiden

J. (2016). Lean UX: Designing Great Products with Agile Teams (2nd ed.). O'Reilly Media.

Reference: Chapter 5

"Hypotheses

" pp. 71-86. The authors describe how personas are used to frame a hypothesis statement: "We believe that [building this feature] for [these personas] will achieve [this outcome]." This directly links personas to the formulation of value hypotheses (supporting B).

3. Miaskiewicz

T.

& Kozar

K. A. (2011). Personas and user-centered design: How can personas benefit a design process? Design Studies

32(5)

417-430.

Reference: Section 3

"Benefits of Personas

" p. 421. The paper discusses how personas help teams maintain a focus on the target market. By representing specific segments

they aid in strategic thinking about market fit and potential (supporting C). DOI: https://doi.org/10.1016/j.destud.2011.03.003

4. Chapman

C. N.

& Milham

R. P. (2006). The personas' new clothes: Methodological and practical arguments against a popular method. Proceedings of the Human Factors and Ergonomics Society Annual Meeting

50(5)

634-636.

Reference: p. 634. While critical of poor persona implementation

this academic paper acknowledges that a key intended use of personas in marketing is to understand "customer motivations and buying triggers" by creating a vivid picture of the target customer (supporting D). DOI: https://doi.org/10.1177/154193120605000503

The scenario describes a gap between the assumed value of features and their actual value, as evidenced by usage data. A Product Owner's response should be guided by empiricism—inspecting the outcome and adapting. All four actions are valid empirical methods to further evaluate the situation. Talking to users (A) and examining the problem-solution fit (D) provide crucial qualitative insights into the "why" behind the data. Running experiments (C) is a core tenet of modern product management to test hypotheses. Disabling features to listen for feedback (B) is a specific, powerful experiment to validate the low-value assumption. These actions help the Product Owner gather evidence to make informed decisions about the product's future.

All the provided options are correct as they represent valid, empirical approaches a Product Owner can take to investigate user behavior and product value.

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

Reference: Page 4

"Conducting Experiments to Improve Value."

Quote/Concept: "Once an organization has a way to measure value

it can conduct experiments to improve it. The results of these experiments

in turn

provide new evidence." This directly supports options B and C. The guide's focus on understanding customer outcomes also supports A and D.

2. McGreal

D.

& Jocham

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

Reference: Chapter 5

"Value

" specifically the section on "Validating Value" (pp. 61-63).

Concept: This chapter emphasizes moving from measuring output to outcomes. It advocates for hypothesis-driven development

A/B testing

and gathering direct user feedback to understand what is truly valuable

which aligns with all four options.

3. Schwaber

K.

& Sutherland

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

Reference: Page 3

"Scrum Theory."

Quote/Concept: "Scrum is founded on empiricism... Empiricism asserts that knowledge comes from experience and making decisions based on what is observed." The scenario is an observation

and all the proposed actions are ways to gain more experience and knowledge before making a decision.

4. Blank

S. (2013). Why the lean start-up changes everything. Harvard Business Review

91(5)

63-72.

Reference: The core concept of the "build-measure-learn" feedback loop.

Concept: The team has "built" a feature and "measured" its low usage. The options (A

B

C

D) all represent the "learn" phase

which is critical for deciding what to build or adapt next. This is a foundational concept in modern product management taught in university business programs.

Effective Product Backlog management is an ongoing process led by the Product Owner to maximize the value of the product. This involves more than just creating a list. It includes ordering items based on value, risk, and dependencies to best achieve the Product Goal (E). A key part of this is Product Backlog refinement, which involves breaking down large, ambiguous items into smaller, more precise ones (D) and working to reduce dependencies between them to allow for flexible ordering and smoother development (B). Furthermore, continuous collaboration and review with stakeholders are essential to ensure the backlog remains transparent, understood, and aligned with their needs and the evolving market (C).

A. Forecasting the effort of Product Backlog items.

This is incorrect because while the Product Owner uses estimates for ordering and planning, the Developers are the ones responsible for creating the estimates (sizing) of the work.

1. Schwaber

K.

& Sutherland

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

Reference for D & E: Page 12

"Product Backlog" section: "Product Backlog management includes: ... Creating and clearly communicating Product Backlog items; Ordering Product Backlog items;..." Breaking down items is a core part of creating clear items (refinement).

Reference for C: Page 6

"Product Owner" section: "The Product Owner may represent the needs of many stakeholders in the Product Backlog... For Product Owners to succeed

the entire organization must respect their decisions." This necessitates reviewing the backlog with them.

Reference for B: While not explicitly stated as "reducing dependencies

" this is a crucial part of refinement. The guide states refinement is the "act of breaking down and further defining Product Backlog items into smaller more precise items." A key aspect of making items precise and ready for a Sprint is ensuring they are as independent as possible to facilitate flexible ordering and delivery.

Reference for A (Incorrect): Page 9

"Developers" section: "The Developers are always accountable for: ... Instilling quality by adhering to a Definition of Done; ... Sizing Product Backlog items."

2. Pichler

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

Reference for B

C

D

E: Chapter 3

"Working with the Product Backlog

" discusses grooming (refinement) activities which include breaking down items (p. 47)

collaborating with the team and stakeholders (p. 45)

and managing dependencies (p. 53). The entire chapter is dedicated to these management activities.

The Definition of Done (DoD) is a formal commitment within Scrum that serves as a shared understanding of what it means for work to be complete on the product Increment. Its primary purpose is to increase transparency (A) by ensuring everyone, including the Product Owner, Developers, and stakeholders, operates with the same definition of quality and completeness. This creates a shared understanding of when a Product Backlog Item is finished (C). Furthermore, the DoD is a critical input for Sprint Planning, as it informs the Developers' forecast. A more stringent DoD implies more work per item, which directly influences how many items they can realistically select for a Sprint (E).

B. The purpose, objective, and timebox of each Scrum event are explicitly described in the Scrum Guide itself, not in the Definition of Done.

D. A Sprint is declared complete when its timebox expires, regardless of whether all work is finished. The DoD applies to the Increment, not the Sprint's completion.

1. Schwaber

K.

& Sutherland

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

For A & C: "The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product... This increases transparency by providing everyone a shared understanding of what work was completed as part of the Increment." (p. 10).

For E: "Selecting how much can be completed within a Sprint may be challenging. However

the more the Developers know about their past performance

their upcoming capacity

and their Definition of Done

the more confident they will be in their Sprint forecasts." (p. 8).

For D (Incorrect): "Sprints are the heartbeat of Scrum

where ideas are turned into value. They are fixed length events of one month or less... A new Sprint starts immediately after the conclusion of the previous Sprint." (p. 7). This establishes the timeboxed nature of a Sprint's completion.

The fundamental accountability of the Product Owner is to maximize the value of the product resulting from the work of the Scrum Team. This is the ultimate measure of their success. All other responsibilities, such as managing the Product Backlog, defining release contents, and engaging with stakeholders, are means to achieve this primary objective. The Product Owner makes strategic decisions and trade-offs, always with the goal of optimizing the value delivered to the market, users, and the organization.

A. This is a part of the Product Owner's role, but these decisions are driven by the primary goal of maximizing value, making it a tactical activity rather than the most important thing.

B. Satisfying all stakeholder needs is often impossible due to conflicting interests. The Product Owner must balance these needs and make choices that best serve the product's overall value.

C. The Product Owner manages the Product Backlog, which is the single source of requirements. However, this is a mechanism to achieve transparency and order, not the ultimate goal itself.

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

2. Hohl

P.

Klünder

J.

van der Vliet

H.

& Gorschek

T. (2018). The Product Owner Role in Scrum: A Systematic Literature Review. In Product-Focused Software Process Improvement (pp. 3-19). Springer

Cham. Section 4.1

"Results

" consistently identifies "Value Maximizer" as a primary facet of the Product Owner role synthesized from numerous academic studies. DOI: https://doi.org/10.1007/978-3-030-03673-11

3. MIT OpenCourseWare. (2010). 15.563 System Dynamics for Business Policy. Massachusetts Institute of Technology. Lecture 22

"Managing Product Development

" discusses how roles like the Product Owner are crucial for steering projects toward delivering maximum business value

which is the central theme of effective product management in agile frameworks.

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)

During a Sprint, the Product Owner's primary focus is on maximizing the value of the product resulting from the work of the Developers. This involves several ongoing activities. The Product Owner is responsible for the Product Backlog, which is a living artifact; they continuously refine and reorder it as new information emerges from stakeholders or the market (A). They collaborate closely with the Developers, clarifying requirements and answering questions about the Sprint Backlog items to ensure a shared understanding (B). Furthermore, a crucial part of the role is continuous engagement with stakeholders to gather feedback, manage expectations, and validate the product direction, which informs future backlog ordering (E).

C. Update the Sprint burndown chart.

The Sprint Backlog and its progress visualizations are owned and managed by the Developers. The Product Owner does not update these artifacts.

D. Prioritize the Developer's tasks.

The Product Owner orders the Product Backlog. The self-managing Developers determine how to accomplish the work within the Sprint, including the order of their tasks.

F. Run the Daily Scrum.

The Daily Scrum is an event for the Developers to inspect progress and adapt their plan. The Product Owner does not run or facilitate this meeting.

1. Schwaber

K.

& Sutherland

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

For A & E: Page 6

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

which includes: ... Ordering Product Backlog items... 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 management is a continuous activity. The PO represents stakeholders

which requires ongoing communication.

For B: Page 7

"For Product Owners to succeed

the entire organization must respect their decisions... The Product Owner is one person

not a committee. The Product Owner may represent the needs of many stakeholders in the Product Backlog." This implies they are the point of clarification for the Developers.

For C & D: Page 9

"The Sprint Backlog is a plan by and for the Developers. It is a highly visible

real-time picture of the work that the Developers plan to accomplish during the Sprint in order to achieve the Sprint Goal."

For F: Page 10

"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 they do not run the event in their PO capacity.

2. Hohl

P.

Klünder

J.

van der Veen

A.

& Gorschek

T. (2018). A large-scale study on the motivations for using agile practices. In Proceedings of the 22nd International Conference on Evaluation and Assessment in Software Engineering 2018 (pp. 173-183). https://doi.org/10.1145/3210459.3210478

This study reinforces the PO's role in continuous communication with both the team (clarifying requirements) and stakeholders (gathering feedback) as a core practice for achieving product value. (Section 4.1

Table 2).

In environments of high uncertainty, Scrum's empirical nature is paramount. The primary goal is to reduce uncertainty by learning as quickly as possible. This is achieved through a cycle of forming a hypothesis, building a small experiment to test it, and learning from the results.

Focusing on validating customer needs (B) is the direct approach to tackling the uncertainty. Instead of building based on assumptions, the Product Owner prioritizes work that helps to prove or disprove hypotheses about what is valuable to the customer.

Making each release smaller (A) is the mechanism that enables this rapid validation. Small, frequent releases allow the team to get real-world feedback from users quickly, minimizing investment in the wrong direction and accelerating the learning loop.

C. the more likely it is that you should invest in a different product.

This is a premature conclusion. High uncertainty necessitates exploration and validation first; abandoning the product is a possible outcome of that validation, not the immediate response.

D. the more important a risk management plan becomes.

Scrum manages risk empirically through its iterative process (short Sprints, frequent feedback), not through a traditional, predictive "risk management plan" document. Options A and B describe this empirical approach.

---

1. Scrum.org

"The Evidence-Based Management Guide." January 2019.

Reference: Page 4

"An Empirical Approach."

Quote/Concept: The guide states

"EBM helps organizations to deliberately put their hypotheses to the test

to learn from their experiments

and to pivot their direction based on the evidence they uncover." This directly supports focusing on validation (B) to navigate uncertainty.

2. Ries

E. (2011). The Lean Startup: How Today's Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses. (While a commercial book

its principles are foundational in university entrepreneurship and software engineering curricula and are cited extensively in academic papers on Agile).

Reference: Chapter 5

"Leap

" and Chapter 6

"Test."

Quote/Concept: The core principle of the Build-Measure-Learn feedback loop is to test fundamental business hypotheses. This is done by building a Minimum Viable Product (MVP)

which is a small version of a product/release (A)

for the express purpose of learning and validating needs (B).

3. Cruzes

D. S.

Rodrigues

M. A. F.

& de Souza

F. A. F. (2015). "Risk Management in Agile Software Development: A Survey." 2015 10th International Conference on the Quality of Information and Communications Technology

pp. 189-194.

Reference: Section III-A

"Risk Management in Agile Methods."

Quote/Concept: The paper highlights that agile methods manage risks

including market and requirement uncertainty

through "short iterations

constant feedback from the customer

and refactoring." This supports the use of small increments/releases (A) over traditional risk plans (D).

DOI: https://doi.org/10.1109/QUATIC.2015.38

The user satisfaction gap, a core concept in product management and value delivery, is the discrepancy between what a user wants to achieve (their desired outcome) and what they actually experience when using a product. This concept is rooted in Expectation-Confirmation Theory, where satisfaction is a function of comparing pre-use expectations against post-use perceived performance. A Product Owner's goal is to minimize this gap by ensuring the product delivers value that meets or exceeds user expectations, thereby maximizing user satisfaction and, consequently, the value of the product.

A. The total market size. This is a business metric representing the entire potential customer base or revenue, not an indicator of individual user satisfaction or experience.

C. The market share of the product. This metric reflects a product's sales performance relative to competitors, not the qualitative gap between a user's expectations and their actual experience.

---

1. Parasuraman

A.

Zeithaml

V. A.

& Berry

L. L. (1985). A Conceptual Model of Service Quality and Its Implications for Future Research. Journal of Marketing

49(4)

41–50. This seminal paper introduces the "gap model" of service quality

where "Gap 5" is identified as the discrepancy between customer expectations and their perceptions of the service delivered (i.e.

their actual experience). This is the foundational concept of the user satisfaction gap. (DOI: https://doi.org/10.2307/1251430)

2. Oliver

R. L. (1980). A Cognitive Model of the Antecedents and Consequences of Satisfaction Decisions. Journal of Marketing Research

17(4)

460–469. This paper establishes the Expectation-Confirmation Theory (ECT)

which posits that satisfaction is determined by comparing a user's initial expectations (desired outcome) with the product's perceived performance (actual experience). (DOI: https://doi.org/10.2307/3150499)

3. Schwaber

K.

& Sutherland

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

"The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team" (p. 5). Maximizing value is directly achieved by understanding and fulfilling user needs

which involves closing the gap between their desired outcomes and their actual experience with the product.

The Product Owner's primary accountability is to maximize the value of the product, a goal best achieved through empiricism. The Scrum framework is founded on transparency, inspection, and adaptation. By continuing to measure and publish the usage data (B), the Product Owner upholds the pillar of transparency. This allows all stakeholders, including the dissenting one, to inspect the same facts. This data-driven approach enables informed decisions (adaptation) about the product's future, ensuring that development effort is focused on features that deliver real value. While managing stakeholder relationships is crucial, it must not override the empirical process that is fundamental to Scrum's success and the PO's accountability.

A. Hiding the data violates the Scrum pillar of transparency, which erodes trust and prevents collective inspection and informed decision-making by all stakeholders.

C. This choice abandons empiricism in favor of a single stakeholder's opinion, directly contradicting the PO's accountability to maximize value based on evidence.

1. Schwaber

K.

& Sutherland

J. (2020). The Scrum Guide.

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." This supports using the observed usage data to make decisions.

Page 4

"Transparency": "The emergent process and work must be visible to those performing the work as well as those receiving the work... Artifacts that have low transparency can lead to decisions that diminish value and increase risk. Transparency enables inspection." This supports publishing the data

not hiding it.

Page 5

"Product Owner": "The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team." This accountability is fulfilled by making data-driven decisions

not by appeasing stakeholders.

2. McGreal

D.

& Jocham

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

Chapter 4

"Value

" Section "Evidence-Based Management

" p. 61: The text emphasizes using empirical measures to guide decisions

stating

"Without measurement

you are just another person with an opinion." This directly supports prioritizing verified data over a stakeholder's unsubstantiated belief.

3. Verwijs

C.

Russo

D.

& Stol

K. J. (2023). A Theory of Scrum Team Effectiveness. ACM Transactions on Software Engineering and Methodology

32(4)

Article 95.

Section 3.2.1

"Valuable Product": The theory posits that effectiveness is linked to delivering a valuable product

which is assessed through "feedback from the relevant environment." The customer usage data is a direct form of this feedback

making it essential for the PO to use and share it. (https://doi.org/10.1145/3592659)

Scrum does not use a traditional, static "project plan." Instead, the plan is emergent and is represented by the Product Backlog. The Product Backlog is a living artifact that contains all known requirements, features, and work for the product. The Product Owner is accountable for managing this backlog. It is continuously updated and refined throughout the product's lifecycle as the Scrum Team and stakeholders learn more about the product and the market. This adaptive planning approach is a core tenet of Scrum's empiricism, allowing for flexibility and responsiveness to change.

A. The Daily Scrum is a planning event for the Developers to inspect progress toward the Sprint Goal, not a status meeting for the Product Owner to update a plan.

B. The Sprint Retrospective is an event focused on inspecting and improving the Scrum Team's processes, interactions, and tools, not for updating the product or project plan.

D. While the Product Backlog should be refined before Sprint Planning, updating it is a continuous activity, not a singular event. Developers, not the PO, select the work for the Sprint.

1. The Scrum Guide (2020):

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

K.

& Sutherland

J.

2020

p. 11). This establishes the Product Backlog as the plan.

"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

estimates

and order to them." (Schwaber

K.

& Sutherland

J.

2020

p. 12). This confirms the continuous nature of updates.

2. Peer-reviewed Academic Publication:

Hohl

P.

et al. (2018). Backlog Refinement in Large-Scale Agile System Development. In Agile Processes in Software Engineering and Extreme Programming - Workshops. "The PBL [Product Backlog] is a living artifact that is continuously updated based on the changing reality of the project." (p. 1

Section 1). DOI: https://doi.org/10.1007/978-3-319-98339-71

3. University Courseware:

University of Virginia

Darden School of Business: In the course "Agile Development in Practice

" the Product Backlog is described as the "dynamic

ordered list of work to be done

" which serves as the project's plan and is expected to evolve over time. (Course materials on Agile artifacts).

The Sprint Backlog is a plan by and for the Developers. During Sprint Planning, the Developers select Product Backlog Items for the Sprint and create an initial plan for delivering them. This plan, which is the Sprint Backlog, does not need to be complete or exhaustive. It must be detailed enough for the Developers to forecast what they believe can be accomplished to meet the Sprint Goal and to start the work of the Sprint. The Sprint Backlog is emergent and will be refined throughout the Sprint as the Developers learn more about the work needed to achieve the Sprint Goal.

B. The Sprint Backlog is emergent and evolves as more is learned. Requiring 100% of the work to be identified upfront is contrary to Scrum's empirical nature.

C. Understanding design and architecture is part of the work, but the Sprint Backlog's primary purpose is to be an actionable plan for the Developers to achieve the Sprint Goal.

D. The Sprint Backlog is owned and managed by the Developers. Their confidence and understanding are paramount, not the Scrum Master's, who serves as a facilitator.

---

1. Schwaber

K.

& Sutherland

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

Page 9

"Sprint Planning" section: "The Developers select items from the Product Backlog to include in the current Sprint... Through discussion with the Product Owner

the Developers select items from the Product Backlog to include in the current Sprint. The Scrum Team may refine these items during this process

which increases understanding and confidence. Selecting how much can be completed within a Sprint may be challenging. However

the more the Developers know about their past performance

their upcoming capacity

and their Definition of Done

the more confident they will be in their Sprint forecasts."

Page 10

"Sprint Backlog" section: "The Sprint Backlog is a plan by and for the Developers... It is updated throughout the Sprint as more is learned. It should have enough detail that they can inspect their progress in the Daily Scrum."

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

"Planning the day": This study reinforces that detailed planning is an ongoing

daily activity

not a one-time event in Sprint Planning. The Sprint Backlog created in planning is a starting point

"The team members created a plan for the next 24 hours... This plan was often a refinement of the overall sprint plan." This supports the idea that the initial plan is not exhaustive.

The best measure of a valuable product Increment is the positive change it creates for its users and the business. This change is best described as an "outcome." An outcome focuses on the result and the value delivered (e.g., "users can find a product 20% faster"), rather than the output (e.g., "a new search bar was added"). A releasable Increment should be the smallest possible piece of work that achieves a specific, valuable outcome for the user. This approach ensures that each release delivers tangible value and allows for rapid feedback and learning, which is a core principle of Scrum.

B. Adds a new feature.

This is incorrect because it focuses on output (a feature) rather than outcome (the value the feature provides). A feature might not deliver any real value to the user.

C. Fixes at least one defect.

While fixing a critical defect can be valuable, it is not the sole definition of a valuable Increment. The primary goal is typically to deliver new or improved outcomes.

D. Delivers all "must do" Product Backlog items.

This contradicts the principle of delivering the "smallest" valuable Increment. Bundling all "must do" items can create a large batch, delaying the delivery of value and feedback.

1. Scrum.org

"The Evidence-Based Management Guide" (2020). This guide explicitly distinguishes between outputs and outcomes. It states

"Organizations need to focus more on outcomes

which are the changes in stakeholder behaviors that drive changes in value... Outcomes are the desirable results that customers and users experience by using the organization’s products or services." (p. 5

10). This supports focusing on delivering an outcome as the measure of value.

2. Schwaber

K.

& Sutherland

J. "The Scrum Guide" (November 2020). The guide defines an Increment as "a concrete stepping stone toward the Product Goal... In order to provide value

the Increment must be usable." (p. 10). While it doesn't use the word "outcome

" the emphasis on "usable value" aligns with achieving a desired result for the user

which is an outcome.

3. McGrath

R. G. (2010). "The End of Competitive Advantage: How to Keep Your Strategy Moving as Fast as Your Business." Harvard Business Review Press. While not a Scrum-specific text

this foundational business strategy work emphasizes the need for organizations to deliver continuous value through small

iterative experiments that produce measurable outcomes

a principle directly embodied in option A. (Chapter 4: "Innovation Proficiency").

Agility in product development is the ability to adapt to market changes and customer needs to continuously deliver value. Leaning on existing organizational structures and architecture, as suggested in option D, is antithetical to this principle. This approach, often an example of Conway's Law in effect, forces the product to conform to internal constraints rather than evolving to meet market demands. It prioritizes internal efficiency and the status quo over customer value and adaptability, creating rigidity and technical debt that directly impede agility. True agility often requires the organization and its architecture to evolve in service of the product and its customers.

A. Understanding market size is a fundamental part of product validation and maximizing value, which is a core tenet of agile product management.

B. A holistic customer view is essential for empathy, building the right product, and ensuring it delivers real value, which is the primary goal of agility.

C. Understanding the producer/consumer relationship clarifies value exchange and stakeholder needs, enabling better, more agile prioritization and decision-making.

1. The Scrum Guide (2020): The guide defines Scrum as a framework for "developing

delivering

and sustaining complex products" through empiricism

which requires adaptation. The Product Owner's role is to maximize value

which necessitates a focus on the market and user

not internal organizational convenience. (Schwaber

K.

& Sutherland

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

2. Scrum.org

The Professional Scrum Competencies: The "Evolving the Agile Organization" competency explicitly states that for agility to flourish

"The organization's structure and culture must be adapted to support agility." This directly contradicts the idea of aligning the product to the current organization. (Scrum.org. (n.d.). The Professional Scrum Competencies. Retrieved from scrum.org/professional-scrum-competencies. Section: Evolving the Agile Organization).

3. Conway

M. E. (1968). How Do Committees Invent? Datamation

14(5)

28-31. This foundational paper introduces what is now known as Conway's Law

stating that organizations design systems that mirror their own communication structures. Relying on this as a strategy

rather than consciously designing the organization to support the desired product architecture

is a well-known barrier to agility and innovation.