PSPO-I Practice Exam Questions with Answers Professional Scrum Product Owner (PSPO I) Exam Certification

During the Sprint Review, the stakeholder’s role is not to reorder the Product Backlog, but rather to provide feedback and suggestions on the product and the process. Therefore, the answer is false because:

• The Sprint Review is an informal meeting, not a status meeting, and the presentation of the Increment is intended to elicit feedback and foster collaboration. The stakeholders are invited to attend the Sprint Review as observers, participants, or customers, and they can share their opinions, ideas, or requests regarding the product and its features, functionality, quality, value, etc.
• The ordering of the Product Backlog is the sole responsibility of the Product Owner. They order Product Backlog items to best achieve goals and missions. The Product Owner may consider the feedback and suggestions from the stakeholders, as well as other factors such as dependencies, risks, costs, etc., when ordering the Product Backlog. However, they are not obliged to follow or implement them.
• The Product Backlog is not a fixed or final list of requirements, but rather an emergent and dynamic artifact that represents all the possible changes to the product. The Product Owner is accountable for effective Product Backlog management, which includes refining, communicating, and optimizing the Product Backlog items. The Product Owner may update the Product Backlog at any time, not only during the Sprint Review.

References:

• Scrum Guide 2020, page 11: “The ordering of the items in the Product Backlog is the sole responsibility of the Product Owner.”
• Scrum Guide 2020, page 11: “The Product Owner is accountable for effective Product Backlog management, which includes … ordering Product Backlog items; and ensuring that the Product Backlog is transparent, visible and understood.”
• Scrum Guide 2020, page 15: “The Sprint Review is an informal meeting, not a status meeting, and the presentation of the Increment is intended to elicit feedback and foster collaboration.”

Correct Answer: A. Teach them that it is their responsibility to work with the other teams to create an integrated Increment that is inclusive of all five team’s work.

Explanation: According to the Scrum Guide, the Scrum Team is responsible for all product-related activities, including coordination and integration with other teams. The Scrum Master should teach the Developers how to work with the other teams to create a potentially releasable product increment that meets the Definition of Done and the Product Goal. One way to facilitate this coordination is to use a Scrum of Scrums meeting, which is a daily or periodic meeting where representatives from each team share their progress, plans, and impediments. The Scrum of Scrums meeting is not mandatory, but it can help the teams align their work and resolve dependencies.

The other options are not correct because they violate the principles of Scrum, such as self-management, empiricism, and transparency:

• B. Collecting the Sprint tasks from the teams and merging them into a consolidated plan for the entire Sprint is a centralized and controlled way of coordination that undermines the self-management and autonomy of the teams. The Scrum Master should not act as a project manager or a coordinator, but as a servant-leader and a coach who enables the teams to manage their own work.
• C. Visiting the five teams each day to inspect that their Sprint Backlogs are aligned is a micromanagement and inspection approach that does not respect the trust and transparency of the teams. The Scrum Master should not interfere with the work of the teams, but support them in creating a shared understanding of the product vision, goals, and requirements.
• D. Teaching the Product Owner to work with the lead developers on ordering Product Backlog in a way to avoid too much overlap during a Sprint is a suboptimal and inefficient way of coordination that does not leverage the collective intelligence and creativity of the teams. The Product Owner should not rely on a few individuals to order the Product Backlog, but collaborate with all the teams and stakeholders to maximize value delivery.

References:

• [Scrum Guide], section 2.2: “The Scrum Team is responsible for all product-related activities from stakeholder collaboration, verification, maintenance, operation, experimentation, research and development, and anything else that might be required.”
• Scrum Of Scrums - Guide to Agile Scaling Frameworks - Agilest®: “The coordination of the various teams is done in a Scrum of Scrums meeting which can be held daily, twice a week, or at a minimum, once a week. Each Scrum team has its ScrumMaster or a designated team member attend the Scrum of Scrum meeting as its representative.”

The Scrum Guide states that "The Increment is the sum of all the Product Backlog items completed during a Sprint and the value of the increments of all previous Sprints. At the end of a Sprint, the new Increment must be ‘Done,’ which means it must be in useable condition and meet the Scrum Team’s definition of ‘Done.’"1 This means that a valuable and useful Increment must be available at the end of every Sprint, regardless of the release frequency or the Product Owner’s request. This ensures transparency, feedback, and continuous improvement.

References:

• 1: The Scrum Guide2, page 14
• 2: The Scrum Guide

Explanation: The Product Owner is responsible for managing and refining the Product Backlog, which is the single source of truth for the plan of the product development. The Product Backlog is a living artifact that changes as the product and the market evolve. The Product Owner updates the Product Backlog continuously based on feedback, learning, and stakeholder needs. There is no separate project plan document in Scrum.

References:

• [Scrum Guide], section 3.1: “The Product Backlog is an emergent, ordered list of what is needed to improve the product.”
• [Professional Scrum Product Owner], chapter 5: “The Product Backlog represents everything necessary to develop and launch a successful product.”
• [What is a Product Backlog?]: “The Product Backlog is a list of all things that need to be done within the project.”

• The best statement that describes Scrum is: A framework to generate value through adaptive solutions for complex problems.
• Scrum is a lightweight framework that helps people, teams, and organizations to deliver valuable products in complex and uncertain environments.
• Scrum is based on empiricism, which means that knowledge comes from experience and making decisions based on what is observed. Scrum employs an iterative and incremental approach to optimize predictability and control risk.
• Scrum is not a defined and predictive process, a complete methodology, or a cookbook that defines best practices. Scrum provides the minimal boundaries within which teams can self-organize and create innovative solutions. References: Scrum Guide, Section 1 (Definition of Scrum) and Section 2 (Uses of Scrum)

The Sprint Retrospective is one of the five events defined by Scrum. It is a formal opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint. The purpose of the Sprint Retrospective is to adapt the way of working so that it becomes more effective and enjoyable. The other options are not required by Scrum, but may be useful practices depending on the context. Developers do not have to stand up at the Daily Scrum, they can choose any format that works for them. A Sprint Burndown Chart is a common way to visualize the remaining work in a Sprint, but it is not mandated by Scrum. Release Planning is a topic that falls under the broader competency of Managing Products with Agility, but it is not a prescribed event in Scrum.

References:

• The Scrum Guide
• Understanding and Applying the Scrum Framework
• Professional Scrum Product Owner™ I Certification

The advantages of a Product Owner sharing a clearly defined Product Goal with the Scrum Team are:

• It provides a good overall direction so Sprints will feel less like isolated pieces of work. The Product Goal is a long-term objective for the product that guides all the activities of the Scrum Team. It helps the Scrum Team align their efforts and focus on delivering value that contributes to the product vision.
• It helps the Scrum Team keep focus and they can weigh any decision against the Product Goal. The Product Goal serves as a filter for deciding what to work on and what not to work on. It helps the Scrum Team prioritize and optimize their work based on value and impact.
• It is easier to inspect incremental progress at the Sprint Review. The Sprint Review is an event where the Scrum Team and the stakeholders collaborate on the product and inspect how it meets the Product Goal. The Increment is a concrete and usable outcome of the Sprint that provides a measure of progress towards the Product Goal.

Other options, such as helping the Developers estimate the date that the Product Backlog will be complete or being not mandatory in Scrum, are not valid advantages of having a Product Goal. They may reflect a misunderstanding of what a Product Goal is or how Scrum works.

References:

• [Scrum Guide], page 10, section “Product Goal”
• [Professional Scrum Product Owner™ Training], page 6, section “Product Vision”
• [Professional Scrum Product Owner™ Training], page 7, section “Product Backlog Management”
• [Scrum Guide], page 13, section “Sprint Review”
• [Scrum Guide], page 10, section “Increment”

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. The Product Backlog is dynamic; it constantly changes to identify what the product needs to be appropriate, competitive, and useful. The other options are not accurate descriptions of the Product Backlog, as it does not contain all foreseeable tasks and requirements, it does not provide just enough information to start the design phase, and it is not baselined to follow change management processes23.

1: What is a Product Backlog? | Scrum.org 2: What is a Product Backlog? | Agile Alliance 3: Product Backlog: Definition, Examples & Techniques | Wrike Guide

The Scrum values are commitment, focus, openness, respect, and courage1. These values are embodied by the Scrum Team, which is a self-managing unit that organizes its own work and delivers a valuable product2. The Scrum Team consists of one Scrum Master, one Product Owner, and Developers[3][3]. The best way to create Scrum Teams is to respect the self-management and empowerment of the people who will do the work, and let them decide how to organize themselves into Scrum Teams. This can be done by bringing all the people together and letting them form Scrum Teams based on their skills, interests, and alignment with the product vision4. Alternatively, existing teams can propose how they would like to reorganize themselves into Scrum Teams, based on their feedback and experience5. These ways of creating Scrum Teams are consistent with the Scrum values, as they foster commitment, focus, openness, respect, and courage among the team members and stakeholders. The other options are not consistent with the Scrum values, as they involve managers or the Chief Product Owner imposing their decisions on the team members, which undermines their self-management and empowerment, and creates a lack of trust and collaboration.

References:

1: The Scrum Guide, November 2020, p. 4

2: The Scrum Guide, November 2020, p. 5

[3][3]: The Scrum Guide, November 2020, p. 6

4: Managing Products with Agility, Scrum.org, accessed on December 16, 2023

5: Developing People and Teams, Scrum.org, accessed on December 16, 2023

According to the Scrum Guide, if a Product Backlog item does not meet the Definition of Done, it should not be included in the Increment for the Sprint1. The item is considered unfinished and therefore cannot be part of the Increment that may be released or presented as ‘Done’. The undone work should be re-estimated and put back on the Product Backlog for the Product Owner to prioritize for future Sprints2. This ensures transparency and maintains the integrity of the Increment’s quality.

References: The Scrum Guide provides clear guidance on handling undone work and emphasizes the importance of the Definition of Done as a quality standard for the Increment1. The Professional Scrum Product Owner™ (PSPO I) materials also align with this approach, underscoring the Product Owner’s role in managing the Product Backlog and ensuring that only ‘Done’ items are considered for release

The Scrum Team can maintain the Product Backlog to maximize its transparency by continually keeping it up to date with the most recent insights because:

• It reflects the current state of the product and the work. The Product Backlog is a dynamic and emergent artifact that represents all the possible features, functions, requirements, enhancements, and fixes that constitute changes to the product. By updating it frequently, the Scrum Team can ensure that the Product Backlog is accurate, complete, and relevant.
• It enables the Product Owner to optimize the value of the product and the work of the Scrum Team. The Product Owner is accountable for effective Product Backlog management, which includes ordering, refining, and communicating the Product Backlog items. By updating it frequently, the Product Owner can incorporate new learnings, feedback, opportunities, and changes into the product decisions and priorities.
• It supports the inspection and adaptation of the Scrum Team and the stakeholders. The Product Backlog is a source of information and transparency for everyone involved in the product development. By updating it frequently, the Scrum Team and the stakeholders can inspect the progress and outcomes of each Sprint, and adapt their plans and actions accordingly.

References:

• Scrum Guide 2020, page 10: “The Product Backlog is an emergent, ordered list of what is needed to improve the product.”
• Scrum Guide 2020, page 11: “The Product Owner is accountable for effective Product Backlog management, which includes … ensuring that the Product Backlog is transparent, visible and understood.”
• Scrum Guide 2020, page 11: “The ordering of the items in the Product Backlog is the sole responsibility of the Product Owner. They order Product Backlog items to best achieve goals and missions.”
• Scrum Guide 2020, page 11: “Higher ordered Product Backlog items are clearer and more refined than lower ordered ones.”
• Scrum Guide 2020, page 15: “The Sprint Review is an informal meeting, not a status meeting, and the presentation of the Increment is intended to elicit feedback and foster collaboration.”

• The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team. The Product Owner is responsible for managing and refining the Product Backlog, collaborating with the stakeholders and the Developers, and ordering the items in a way that best achieves goals and missions. The Product Owner represents the interests of everyone with a stake in the product and ensures that the Scrum Team works on the right things at the right time.
• A Sprint is a timebox of one month or less within which a “Done” product Increment is created. A Sprint consists of the Sprint Planning, Daily Scrums, the development work, the Sprint Review, and the Sprint Retrospective. A Sprint is also a feedback loop that allows the Scrum Team and the stakeholders to inspect and adapt the product and the process.
• During a Sprint, a Product Owner is typically responsible for:
• The other options are not valid or relevant responsibilities of a Product Owner during a Sprint. They are either too administrative, micromanaging, or unrelated to the product value delivery. They are:

References:

• Scrum Guide: https://www.scrumguides.org/scrum-guide.html
• Product Owner: https://www.scrum.org/resources/what-is-a-product-owner
• Sprint: https://www.scrum.org/resources/what-is-a-sprint-in-scrum
• Stakeholders: https://www.agilealliance.org/glossary/stakeholders
• Daily Scrum: https://www.scrum.org/resources/what-is-a-daily-scrum

• The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product. The Definition of Done is used to assess when work is complete on the product Increment.
• The Definition of Done is defined by the Scrum Team, not by the Product Owner alone. The Scrum Team consists of one Product Owner, one Scrum Master, and Developers. They are all accountable for creating a valuable, useful, and potentially releasable product Increment each Sprint.
• The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team. The Product Owner is responsible for managing and refining the Product Backlog, collaborating with the stakeholders and the Developers, and ordering the items in a way that best achieves goals and missions. The Product Owner represents the interests of everyone with a stake in the product and ensures that the Scrum Team works on the right things at the right time.
• The Developers are accountable for creating a “Done” Increment that meets the Definition of Done each Sprint. The Developers are responsible for planning and executing the Sprint Backlog, designing and building the product functionality, testing and improving the product quality, and delivering a potentially releasable Increment. The Developers work closely with the Product Owner to understand and clarify the Product Backlog items, provide feedback and estimates, and suggest improvements and innovations.
• The Scrum Master is accountable for establishing Scrum as defined in the Scrum Guide. The Scrum Master is responsible for promoting and supporting Scrum as defined in the Scrum Guide. The Scrum Master does this by helping everyone understand Scrum theory and practice, both within the Scrum Team and the organization.
• The Definition of Done may vary from one Scrum Team to another, depending on the context and domain of work. However, it must be consistent within one team. If there are multiple Scrum Teams working on one product, they must share a common Definition of Done. If there is an organizational standard for a Definition of Done, all Scrum Teams must follow it as a minimum.

References:

• Scrum Guide: https://www.scrumguides.org/scrum-guide.html
• Definition of Done: https://www.scrum.org/resources/what-is-a-definition-of-done
• Product Owner: https://www.scrum.org/resources/what-is-a-product-owner
• Developers: https://www.scrum.org/resources/what-is-a-developer-in-scrum
• Scrum Master: https://www.scrum.org/resources/what-is-a-scrum-master

Cross-functional teams are not optimized to work on one component or layer of a system only. This is because:

• Cross-functional teams are teams that have all the skills and competencies needed to accomplish the work without depending on others who are not part of the team.
• Cross-functional teams are able to deliver value across the entire product, rather than focusing on a specific component or layer. They can work on any aspect of the product that is needed to achieve the Sprint Goal and the Product Goal.
• Cross-functional teams are more agile, collaborative, and creative than teams that are specialized or siloed. They can reduce dependencies, handoffs, and delays, and increase feedback, learning, and adaptation.

References:

• [Scrum Guide], page 7, section “Developers”
• [Scrum Guide], page 10, section “Product Goal”
• [Scrum Guide], page 7, section “The Scrum Team”

 In order to maximize the value of the product, a Product Owner needs awareness of the following:

• Competitive research. The Product Owner should be aware of the competitive landscape and the market trends that affect the product. They should know who are the competitors, what are their strengths and weaknesses, how do they differentiate themselves, and what are their strategies and goals. This can help the Product Owner to identify opportunities, threats, and gaps in the market, and to position the product accordingly.
• Customer feedback. The Product Owner should be aware of the customer needs, preferences, expectations, and satisfaction with the product. They should collect and analyze feedback from various sources, such as surveys, interviews, reviews, analytics, etc. This can help the Product Owner to validate assumptions, test hypotheses, measure outcomes, and discover insights that can inform the product decisions and priorities.
• Product vision. The Product Owner should be aware of the product vision, which is a clear and compelling statement of the desired future state of the product. The product vision describes the purpose, value proposition, target audience, and key features of the product. It also aligns with the organizational vision and mission. This can help the Product Owner to communicate and inspire the stakeholders, to guide and focus the Scrum Team, and to evaluate and adjust the product direction.
• Forecasting & feasibility. The Product Owner should be aware of the forecasting and feasibility of the product. They should estimate and plan the scope, time, cost, quality, and risk of delivering the product. They should also assess the technical, operational, legal, ethical, and social feasibility of developing and releasing the product. This can help the Product Owner to optimize the value of the work of the Scrum Team, to manage expectations and dependencies, and to handle uncertainties and changes.

References:

• Scrum Guide 2020, page 6: “The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team.”
• Scrum Guide 2020, page 11: “The Product Goal describes a future state of the product which can serve as a target for the Scrum Team to plan against.”
• Scrum Guide 2020, page 11: “The Product Owner is accountable for effective Product Backlog management, which includes … optimizing the value of the work the Scrum Team performs.”

The Developers are accountable for managing the progress of work during a Sprint, as they are the ones who plan, execute, and deliver the work. The Scrum Guide states that "The Developers are the people in the Scrum Team that are committed to creating any aspect of a usable Increment each Sprint."1 The Developers are also responsible for conducting the Daily Scrum, a 15-minute event for the Developers to synchronize activities and create a plan for the next 24 hours.1 The Developers are self-managing, which means they decide how best to accomplish their work, rather than being directed by others outside the Scrum Team.1

References:

• 1: The Scrum Guide2, page 7
• 2: The Scrum Guide

Sprint Planning is an event where the Scrum Team collaborates on the work to be performed during the Sprint1. The topics covered in Sprint Planning are:

What can be done. The Product Owner proposes how the product could increase its value and utility in the current Sprint, based on the Product Goal, the Product Backlog, and the latest market and stakeholder feedback. The Developers assess the capacity and the technical feasibility of the work, and select the Product Backlog items that they can commit to for the Sprint. The Scrum Team crafts the Sprint Goal, which is a concise statement of the purpose and focus of the Sprint2.

How to do it. The Developers plan how they will deliver a “Done” product Increment that meets the Sprint Goal. They create a plan for the first days of the Sprint, and decompose the selected Product Backlog items into smaller work items. The Developers also identify any dependencies, risks, or impediments that may affect their work. The resulting plan is captured in the Sprint Backlog, which is owned and managed by the Developers[3][3].

Why to do it. The Product Owner explains the value and the outcome of the work to be done in the Sprint, and how it aligns with the Product Goal and the stakeholder needs. The Product Owner also clarifies the acceptance criteria and the Definition of Done for the Product Backlog items, and answers any questions from the Developers. The Scrum Team ensures that they have a common understanding of the Sprint Goal and the expected product Increment4.

References:

1: The Scrum Guide, November 2020, p. 9

2: The Scrum Guide, November 2020, p. 10

[3][3]: The Scrum Guide, November 2020, p. 10

4: Understanding and Applying the Scrum Framework, Scrum.org, accessed on December 16, 2023

Correct Answers: A, C, and D.

Explanation: The Sprint Retrospective is an event where the Scrum Team reflects on how they worked together in the last Sprint and identifies ways to improve their collaboration, processes, and quality. Therefore, appropriate topics for discussion in a Sprint Retrospective are:

• Team relations: The Scrum Team should discuss how they communicated, interacted, and supported each other during the Sprint. They should celebrate their successes, acknowledge their challenges, and address any conflicts or issues that arose. They should also share feedback, appreciation, and suggestions for improvement with each other.
• How the Scrum Team does its work: The Scrum Team should inspect the methods, tools, and practices they used to deliver the product increment. They should evaluate what worked well and what could be improved. They should also identify any impediments, risks, or dependencies that affected their work and how they handled them.
• Definition of Done: The Scrum Team should review their Definition of Done and check if it is still relevant, clear, and achievable. They should also assess how well they adhered to it and if they delivered a potentially releasable product increment that meets the quality standards. They should also consider if they need to update or adapt their Definition of Done based on new insights or feedback.

The following topics are not appropriate for discussion in a Sprint Retrospective:

• The value of work currently represented in the Product Backlog: The value of the Product Backlog items is the responsibility of the Product Owner, who should continuously refine and order them based on stakeholder needs and feedback. The value of the Product Backlog items is not directly related to how the Scrum Team works together and does not affect their improvement actions for the next Sprint.
• Arranging the Sprint Backlog for the next Sprint: The Sprint Backlog is the plan for the next Sprint that is created by the Scrum Team during the Sprint Planning event. The Sprint Backlog is based on the Product Backlog items that are selected for the next Sprint and how the Developers intend to accomplish them. The Sprint Retrospective is not a planning event but a reflection event that focuses on the past Sprint.

References:

• [Scrum Guide], section 3.5: “The purpose of the Sprint Retrospective is to plan ways to increase quality and effectiveness.”
• [Professional Scrum Product Owner], chapter 7: “The Sprint Retrospective is an opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint.”
• What is a Sprint Retrospective? | Scrum.org: “During each Sprint Retrospective, the Scrum Team plans ways to increase product quality by improving work processes or adapting the definition of “Done” if appropriate and not in conflict with product or organizational standards.”
• The Sprint Retrospective - What It Is & Tips for Making the Most of Your Meeting: “The focus is on how the team worked together in the last sprint, including: Communication Teamwork Process Tools Systems Work environment Missing competencies Collaboration with external parties”

The metrics that will help a Product Owner determine if a product is delivering value are customer satisfaction and time to market. This is because:

• Customer satisfaction is a measure of how well the product meets the needs and expectations of the customers5. It reflects the value proposition of the product and the feedback from the users.
• Time to market is a measure of how quickly the product can be delivered to the market. It reflects the agility and responsiveness of the Scrum Team and the ability to deliver value early and often.

Other metrics, such as productivity, velocity, and percentage of scope implemented, are not directly related to value delivery. They may indicate how efficiently or effectively the Scrum Team is working, but they do not necessarily reflect how valuable or desirable the product is for the customers or stakeholders.

References:

• Professional Scrum Product Owner™ Training, page 5, section “Product Value”
• Professional Scrum Product Owner™ Training, page 6, section “Product Vision”
• Professional Scrum Product Owner™ Training, page 7, section “Product Backlog Management”
• Professional Scrum Product Owner™ Training, page 8, section “Release Management”
• Professional Scrum Product Owner™ Training, page 9, section “Business Strategy”
• Professional Scrum Product Owner™ Training, page 10, section “Stakeholders & Customers”

 Management that is external to the Scrum Team is not involved in the Daily Scrum because:

• The Daily Scrum is an event for the Developers to inspect their progress towards the Sprint Goal and adapt their Sprint Backlog accordingly. It is not a status meeting or a reporting session for managers or other stakeholders.
• The presence of external managers may hinder the self-organization, collaboration, and transparency of the Developers. It may also create pressure, interference, or distraction for the team.
• The Scrum Master is responsible for ensuring that the Daily Scrum is held and that only the Developers participate. The Product Owner and other stakeholders may attend as observers, but only if the Developers find it useful.

References:

• Scrum Guide 2020, page 12: “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.”
• Scrum Guide 2020, page 13: “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.”
• Scrum Guide 2020, page 13: “The Daily Scrum is an internal meeting for the Developers. If others are present, the Scrum Master ensures that they do not disrupt the meeting.”

The value delivered by a product can not be determined by revenue alone, because:

• Revenue is only one aspect of value, and it may not reflect the true impact or benefit of the product for the stakeholders, the users, and the society. For example, a product may generate high revenue, but also cause environmental damage, ethical issues, or customer dissatisfaction.
• Value is a subjective and relative concept, and it may vary depending on the context, the perspective, and the criteria of the evaluation. For example, a product may have different value for different segments of customers, or for different markets or regions.
• Value is dynamic and emergent, and it may change over time due to various factors, such as feedback, competition, innovation, or regulation. For example, a product may lose its value as new alternatives or solutions become available, or as customer needs or preferences evolve.

References:

• Scrum Guide 2020, page 6: “The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team.”
• Scrum Guide 2020, page 11: “The Product Goal describes a future state of the product which can serve as a target for the Scrum Team to plan against.”
• Scrum Guide 2020, page 11: “The Product Owner is accountable for effective Product Backlog management, which includes … optimizing the value of the work the Scrum Team performs.”

The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product. The Definition of Done is created by the Scrum Team, not just the Developers. The Scrum Team must have a shared understanding of what it means for work to be complete, to ensure transparency. The Definition of Done is used to assess when work is complete on the product Increment. The Definition of Done may vary significantly per Scrum Team, depending on the context. The Definition of Done evolves over time and is updated whenever the Scrum Team learns more about the product and the environment in which it operates.

References:

• The Scrum Guide
• Understanding and Applying the Scrum Framework
• Professional Scrum Product Owner™ I Certification

The Definition of Done is a shared understanding of what it means for work to be complete, and ensures transparency of the quality of the work done1. A Product Backlog item is considered complete when it meets the Definition of Done, which means that it is usable and potentially releasable, and that it meets the quality standards set by the Scrum Team and the stakeholders2. The other options are not sufficient to determine the completeness of a Product Backlog item, as they may not reflect the actual value and quality of the product.

References:

1: The Scrum Guide, November 2020, p. 13

2: The Scrum Guide, November 2020, p. 6

A Product Owner is accountable for maximizing the value of the product that is the result of the work of the Scrum Team. However, they can delegate some of their responsibilities to others, while still remaining accountable for the work. Two of the responsibilities that can be delegated to others are:

• Attending the Sprint Retrospective. The Sprint Retrospective is an event where the Scrum Team inspects how the last Sprint went with regards to individuals, interactions, processes, tools, and their Definition of Done. The purpose of the Sprint Retrospective is to plan ways to improve quality and effectiveness. The Product Owner may attend the Sprint Retrospective as one of the Scrum Team members who has a stake in the outcome of the product development. However, they can also choose not to attend or delegate their attendance to someone else who can represent their interests and perspectives.
• Attending the Sprint Review. The Sprint Review is an event where the Scrum Team and stakeholders inspect the Increment and adapt the Product Backlog if needed. The purpose of the Sprint Review is to elicit feedback and foster collaboration. The Product Owner is accountable for ensuring that key stakeholders attend the Sprint Review and that they understand what has been done and what can be done next. However, they can also delegate some of their tasks to others who can facilitate or present the Increment on their behalf.

Other options, such as ordering Product Backlog items or developing and communicating the Product Goal, are not responsibilities that can be delegated to others by the Product Owner. They are essential accountabilities that only the Product Owner can perform.

References:

• [Scrum Guide], page 6, section “Product Owner”
• [Scrum Guide], page 18, section “Sprint Retrospective”
• [Scrum Guide], page 17, section “Sprint Review”
• [Scrum Guide], page 11, section “Product Backlog”
• [Scrum Guide], page 10, section “Product Goal”

Scrum

According to the Scrum Guide 2020, the entire Scrum Team is accountable for creating a valuable, useful Increment every Sprint1234. This includes the Developers, the Product Owner, and the Scrum Master4. The Developers are committed to creating any aspect of a usable Increment each Sprint12, while the Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team12. The Scrum Master fosters an environment where the Scrum Team can work effectively1.

• The Sprint Backlog is the set of Product Backlog items selected for the Sprint, plus a plan for delivering the product Increment and realizing the Sprint Goal. The Sprint Backlog is a highly visible, real-time picture of the work that the Developers plan to accomplish during the Sprint, and it belongs solely to the Developers.
• The Developers are accountable for creating a “Done” Increment that meets the Definition of Done each Sprint. The Developers are responsible for planning and executing the Sprint Backlog, designing and building the product functionality, testing and improving the product quality, and delivering a potentially releasable Increment. The Developers work closely with the Product Owner to understand and clarify the Product Backlog items, provide feedback and estimates, and suggest improvements and innovations.
• The Developers are also responsible for updating the Sprint Backlog throughout the Sprint. The Sprint Backlog is a plan with enough detail that changes in progress can be understood in the Daily Scrum. The Developers modify the Sprint Backlog throughout the Sprint, and the Sprint Backlog emerges during the Sprint. This emergence occurs as the Developers work through the plan and learn more about the work needed to achieve the Sprint Goal.
• As new work is required, the Developers add it to the Sprint Backlog. As work is performed or completed, the estimated remaining work is updated. When elements of the plan are deemed unnecessary, they are removed. Only the Developers can change its content and order during a Sprint.

References:

• Scrum Guide: https://www.scrumguides.org/scrum-guide.html
• Sprint Backlog: https://www.scrum.org/resources/what-is-a-sprint-backlog
• Developers: https://www.scrum.org/resources/what-is-a-developer-in-scrum

The reasons why it is important that there is only one Product Owner per product are:

• It is clear who is accountable for the ultimate value of the product. The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team. They are responsible for identifying and articulating the Product Goal, which is a long-term objective for the product that guides all the activities of the Scrum Team.
• It helps avoid barriers to effective communication and rapid decision-making. The Product Owner is the sole person responsible for managing the Product Backlog, which is an emergent, ordered list of what is needed to improve the product. They must ensure that the Product Backlog is transparent, visible, and understood by everyone who needs to work on it. They must also collaborate with the Developers and the stakeholders to refine, order, and prioritize the Product Backlog items based on value and impact.
• The Scrum Team always knows who determines the order of the Product Backlog. The Product Owner has the final authority to decide what items are more important and valuable for the product. They must communicate this order clearly and consistently to the Scrum Team and the stakeholders. They must also respect and support the self-management of the Developers in choosing how best to accomplish their work.

Other options, such as the Scrum Master knowing who acts as their backup while on vacation or it would confuse the stakeholders if they had to work with more than one person, are not valid reasons why it is important that there is only one Product Owner per product. They may reflect a misunderstanding of the roles and accountabilities of the Scrum Team or the stakeholders.

References:

• [Scrum Guide], page 6, section “Product Owner”
• [Scrum Guide], page 11, section “Product Backlog”
• [Scrum Guide], page 12, section “Product Backlog Refinement”
• [Scrum Guide], page 11, section “Product Backlog”
• [Scrum Guide], page 7, section “Developers”

The two best responses to a Project Manager who has raised concerns about progress and money spent are:

• Promote transparency by sharing the Product Backlog and ensuring the Project Manager has access. This helps communicate what is needed to improve the product, what is planned for each Sprint, and what has been done so far. It also helps align expectations and priorities among different stakeholders.
• Have a discussion with the Project Manager; share the current impediments and forecast for the Sprint. This helps address any issues or risks that may affect the delivery of value and the achievement of the Sprint Goal. It also helps provide feedback and adaptation based on the empirical evidence and data.

Other options, such as showing the Earned Value Analysis (EVA) report, Scrum does not have Project Managers so disregard their concerns, or sharing the last stakeholder briefing document prepared by the Product Owner, are not the best responses as they do not reflect how to effectively collaborate and communicate with the Project Manager or how to apply the Scrum values and principles.

References:

• [Scrum Guide], page 11, section “Product Backlog”
• [Scrum Guide], page 15, section “Sprint Backlog”
• [Scrum Guide], page 10, section “Increment”
• [Scrum Guide], page 5, section “Scrum Theory”
• [Scrum Guide], page 4, section “The Scrum Team”

Correct Answer: D. Never. The entire Scrum Team is accountable for creating value every Sprint.

Explanation: According to the Scrum Guide, the Scrum Team consists of one Product Owner, one Scrum Master, and Developers. The Scrum Team is responsible for all product-related activities, including delivering a valuable, usable product increment every Sprint. The Product Owner is accountable for maximizing the value of the product and the work of the Developers. The Developers are accountable for creating a plan for the Sprint, the Sprint Backlog; instilling quality by adhering to a Definition of Done; and adapting their plan each day toward the Sprint Goal. The Scrum Master is accountable for establishing Scrum as defined in the Scrum Guide, helping everyone understand Scrum theory and practice, and removing impediments to the Scrum Team’s progress.

Therefore, the Developers are not individually accountable for the value of a Product Backlog item selected for the Sprint, but collectively accountable as part of the Scrum Team. The value of a Product Backlog item is determined by the Product Owner, who orders the Product Backlog items based on stakeholder needs and feedback. The Developers collaborate with the Product Owner to understand the value and requirements of each Product Backlog item and deliver a potentially releasable product increment that meets the Definition of Done and the Sprint Goal.

References:

• [Scrum Guide], section 2.2: “The Scrum Team is responsible for all product-related activities from stakeholder collaboration, verification, maintenance, operation, experimentation, research and development, and anything else that might be required.”
• Accountabilities in Scrum | Scrum.org: “Scrum has three accountabilities, each with a different focus : Product Owner (green figure) The "What". With a focus on Value, time to market, return on investment and Total Cost of Ownership (TCO). Developers (red figures) The "How". Focus on building something that is Done – that the increment is useable and potentially releasable.”
• What is a Developer in Scrum? | Scrum.org: “The specific skills needed by the Developers are often broad and will vary based on the type of work they are doing. However, the Developers are always accountable for: Creating a plan for the Sprint, the Sprint Backlog Instilling quality by adhering to a Definition of Done Adapting their plan each day toward the Sprint Goal”

The typical size for a Scrum Team is 10 or fewer people, including the Product Owner, the Scrum Master, and the Developers. The Scrum Guide states that "The Scrum Team is small enough to remain nimble and large enough to complete significant work within a Sprint. Fewer than three people decrease interaction and results in smaller productivity gains. Having more than ten people requires too much coordination. Large teams generate too much complexity for an empirical process to be useful."1 This means that the optimal Scrum Team size is between 3 and 10 people, depending on the context and the nature of the work.

References:

• 1: The Scrum Guide2, page 6
• 2: The Scrum Guide

According to Scrum.org, the Developers who will be doing the work are responsible for the sizing of Product Backlog items1. The Product Owner may influence the Developers by helping them understand and select trade-offs1. This implies that the Developers size the items after clarifying requirements with the Product Owner1.

The Scrum Team is a self-managing unit that organizes its own work and delivers a valuable product1. The Scrum Team consists of one Scrum Master, one Product Owner, and Developers2. The Scrum Team is accountable for creating a valuable, useful Increment every Sprint[3][3]. If a Developer is having conflicts with other team members that affect the delivery of the Increment, the Scrum Team is responsible for resolving the issue and deciding whether to remove the Developer from the team or not. The Product Owner, the Scrum Master, and the hiring manager do not have the authority to remove a Developer from the Scrum Team, as this would violate the principle of self-management4.

References:

1: The Scrum Guide, November 2020, p. 5

2: The Scrum Guide, November 2020, p. 6

[3][3]: The Scrum Guide, November 2020, p. 9

4: Understanding and Applying the Scrum Framework, Scrum.org, accessed on December 16, 2023

 The Scrum Team member who is accountable for creating a valuable and usable Increment each Sprint is the Developers. This is because:

• The Developers are accountable for creating a “Done” Increment in every Sprint. They must ensure that every Product Backlog item they work on meets the Definition of Done before it is considered complete.
• The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product. It is a shared understanding among the Scrum Team and the stakeholders of what “Done” means for any Product Backlog item that is selected for a Sprint.
• The Increment is a concrete and usable outcome of the Sprint that provides a measure of progress and value delivery. It must be in useable condition regardless of whether it will be released or not.
• The Developers are self-managing professionals who organize and manage their own work. They decide how to best accomplish their work, rather than being directed by others outside the Scrum Team.

Other options, such as the CEO, the Product Owner, the Scrum Master, or the Scrum Team, are not accountable for creating a valuable and usable Increment each Sprint. They may have different roles and accountabilities in Scrum, but they do not do the actual work of creating a “Done” Increment.

References:

• [Scrum Guide], page 7, section “Developers”
• [Scrum Guide], page 10, section “Definition of Done”
• [Scrum Guide], page 10, section “Increment”
• [Scrum Guide], page 7, section “The Scrum Team”

It is true that the Sprint Backlog is a result of Sprint Planning, and it includes the Sprint Goal. This is because:

• Sprint Planning is an event where the Scrum Team plans for the upcoming Sprint. The purpose of Sprint Planning is to align the entire Scrum Team around a common goal and a plan for delivering an Increment that meets that goal.
• The Sprint Backlog is the set of Product Backlog items selected for the Sprint, plus a plan for delivering them as a “Done” Increment. The Sprint Backlog is owned by the Developers who use it to organize and manage their work during the Sprint.
• The Sprint Goal is a short-term objective that provides guidance and focus to the Scrum Team throughout the Sprint. It is a flexible and negotiable commitment that can be adjusted as more is learned throughout the Sprint.
• The Sprint Backlog is created by the collaborative work of the entire Scrum Team during Sprint Planning. The Product Owner proposes how the product could increase its value and utility in the current Sprint. The Developers discuss how they can deliver a “Done” Increment that meets this proposal. Together, they define a Sprint Goal that summarizes why the Sprint is valuable to stakeholders. Then, they select enough Product Backlog items from the top of the ordered Product Backlog to satisfy the Sprint Goal. Finally, they create a plan for how they will deliver those items as a “Done” Increment.

References:

• [Scrum Guide], page 14, section “Sprint Planning”
• [Scrum Guide], page 15, section “Sprint Backlog”
• [Scrum Guide], page 15, section “Sprint Goal”

A Product Owner orders a Product Backlog in any way they think will maximize the value of the product1. They take various factors into consideration when ordering the Product Backlog such as business value, risk, return on investment (ROI), dependencies and impact1. Dependencies between Product Backlog items and their relevance to achieving the Product Goal are two of these factors12. The availability of the Scrum Master and the number of stakeholders who approve of the item are not valid criteria for ordering the Product Backlog3.

Scrum

Explore

The correct answers are A and D.

A. Coach the Scrum Team to improve its skills, tools and environment over time and adjust the Definition of Done accordingly. This is an appropriate action for a Scrum Master, as it helps the Scrum Team to overcome the impediments that prevent them from delivering a potentially releasable Increment. The Definition of Done should reflect the current reality of the Scrum Team, but also be a source of continuous improvement12.

D. Have the Scrum Team establish a Definition of Done that is actually possible to achieve given current circumstances. This is also an appropriate action for a Scrum Master, as it ensures that the Scrum Team has a clear and shared understanding of what it means to complete a Product Backlog item. The Definition of Done should be realistic and achievable, but also challenging and ambitious12.

B. Refocus the current Sprint on establishing the Scrum Team’s environment instead of delivering an Increment. This is not an appropriate action for a Scrum Master, as it violates the purpose of the Sprint, which is to deliver a valuable product Increment that meets the Sprint Goal. The Scrum Team should not change the Sprint Goal or scope during the Sprint, unless the Product Owner decides to cancel the Sprint3.

C. Encourage the Product Owner to accept partially done Increments until the situation improves. This is not an appropriate action for a Scrum Master, as it compromises the quality and value of the product. The Product Owner should only accept Increments that meet the Definition of Done and the acceptance criteria. Partially done Increments increase technical debt and risk, and reduce transparency and feedback12.

E. Declare the Scrum Team not ready for Scrum. This is not an appropriate action for a Scrum Master, as it undermines the Scrum values and principles. The Scrum Master should support the Scrum Team in adopting and applying Scrum, regardless of the challenges and constraints they face. The Scrum Master should foster a culture of empiricism, self-organization, collaboration, and continuous improvement.

the Product Owner is responsible for refining the Product Backlog, which is an ongoing activity that can occur at any time, including between Sprints. The other options are not typical activities for the Product Owner between Sprints, as the next Sprint starts immediately after the current Sprint1, the project plan is replaced by the Product Backlog2, and the Quality Assurance is done by the Developers of the Scrum Team within the Sprint1.

1: The Scrum Guide | Scrum.org 2: What is a Product Backlog? | Scrum.org

The Daily Scrum is held at the same time and same place because:

• The consistency reduces complexity. By having a fixed time and place for the Daily Scrum, the Developers can avoid wasting time and energy on scheduling, logistics, or coordination issues. They can also establish a routine and a rhythm that helps them focus on their work and their Sprint Goal.
• The consistency increases transparency. By having a fixed time and place for the Daily Scrum, the Developers can ensure that everyone is aware of when and where the meeting takes place, and that everyone has an opportunity to participate and share their progress, plans, and challenges. They can also invite other stakeholders or observers, if they find it useful, to provide feedback or support.
• The consistency enhances collaboration. By having a fixed time and place for the Daily Scrum, the Developers can create a safe and comfortable space for them to communicate, interact, and collaborate with each other. They can also build trust, rapport, and accountability among themselves, and foster a sense of team spirit and ownership.

References:

• Scrum Guide 2020, page 12: “The Daily Scrum is held at the same time and place each day to reduce complexity.”
• Scrum Guide 2020, page 12: “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.”
• Scrum Guide 2020, page 13: “The Daily Scrum is an internal meeting for the Developers. If others are present, the Scrum Master ensures that they do not disrupt the meeting.”

The Definition of Done is a shared understanding of what it means for work to be complete, and ensures transparency of the quality of the work done1. The Increment is the sum of all the Product Backlog items completed during a Sprint and the value of the increments of all previous Sprints2. The Increment must be usable and potentially releasable, meaning that it meets the quality standards set by the Scrum Team and the stakeholders[3][3]. Doing all work needed to meet the Definition of Done enhances the transparency of the Increment, as it ensures that the Increment is truly done and reflects the current state of the product4. The other options do not enhance the transparency of the Increment, as they either introduce unnecessary complexity, delay, or overhead, or do not provide a clear and consistent way to measure the quality of the work done.

References:

1: The Scrum Guide, November 2020, p. 13

2: The Scrum Guide, November 2020, p. 6

[3][3]: The Scrum Guide, November 2020, p. 13

4: Understanding and Applying the Scrum Framework, Scrum.org, accessed on December 16, 2023

 A Sprint may be cancelled when the Sprint Goal becomes obsolete. This is because:

• The Sprint Goal is a short-term objective that provides guidance and focus to the Scrum Team throughout the Sprint. It is a flexible and negotiable commitment that can be adjusted as more is learned throughout the Sprint.
• The Sprint is a container for all other Scrum events and activities. It is a time-box of one month or less during which a “Done” Increment is created that meets the Sprint Goal. The Sprint has a consistent duration throughout a development effort and only changes duration between Sprints.
• A Sprint may be cancelled before it is over by the Product Owner if they determine that the Sprint Goal is no longer valid or valuable. This may happen due to various reasons, such as a significant change in the market, technology, business direction, or customer needs.
• A cancelled Sprint should be rare and exceptional. It implies a waste of time and resources that could have been spent on delivering value. It also disrupts the rhythm and flow of the Scrum Team and the stakeholders.
• When a Sprint is cancelled, any completed and “Done” Product Backlog items are reviewed and potentially released. Any incomplete Product Backlog items are re-estimated and put back on the Product Backlog. The Scrum Team then plans for a new Sprint.

Other options, such as when the Developers determine the product plan is infeasible, when it becomes clear that not everything will be finished by the end of the Sprint, or when the sales department has an important new opportunity, are not valid reasons for cancelling a Sprint. They may reflect a misunderstanding of what a Sprint Goal is or how Scrum works.

References:

• [Scrum Guide], page 15, section “Sprint Goal”
• [Scrum Guide], page 9, section “Sprint”
• [Scrum Guide], page 16, section “Cancelling a Sprint”

The Developers need a Sprint Goal because it gives them a common yet specific goal to focus on during the Sprint. This is because:

• The Sprint Goal is a short-term objective that provides guidance and focus to the Scrum Team throughout the Sprint. It is a flexible and negotiable commitment that can be adjusted as more is learned throughout the Sprint.
• The Developers are accountable for creating a “Done” Increment in every Sprint. They must ensure that every Product Backlog item they work on meets the Definition of Done before it is considered complete.
• The Developers are self-managing professionals who organize and manage their own work. They decide how to best accomplish their work, rather than being directed by others outside the Scrum Team.
• The Developers need a Sprint Goal to align their efforts and collaborate effectively as a team. The Sprint Goal helps them prioritize and optimize their work based on value and impact. The Sprint Goal also helps them cope with uncertainty and complexity by providing a clear direction and a shared purpose.

Other options, such as a Sprint Goal only giving purpose to Sprint 0, Sprint Goals being not valuable, or a Sprint Goal ensuring that all of the Product Backlog items selected for the Sprint are implemented, are not valid reasons why the Developers need a Sprint Goal. They may reflect a misunderstanding of what a Sprint Goal is or how Scrum works.

References:

• [Scrum Guide], page 15, section “Sprint Goal”
• [Scrum Guide], page 7, section “Developers”
• [Scrum Guide], page 10, section “Definition of Done”
• [Scrum Guide], page 10, section “Increment”

The Scrum Guide states that "By the end of the Sprint Retrospective, the Scrum Team should have identified improvements that it will implement in the next Sprint. Implementing these improvements in the next Sprint is the adaptation to the inspection of the Scrum Team itself."1 This means that the Scrum Team may add the high priority process improvements to the Sprint Backlog for the next Sprint, as part of their plan to deliver the Increment and achieve the Sprint Goal. The Sprint Backlog is owned and managed by the Developers, who can update it throughout the Sprint as more is learned.1

References:

• 1: The Scrum Guide2, page 16
• 2: The Scrum Guide

 This is the best answer because it respects the Scrum values of openness, commitment, and focus. The Developers should be transparent about their progress and collaborate with the Product Owner to adjust the Sprint scope accordingly. The Product Owner is responsible for maximizing the value of the product and the work of the Developers, so he or she should be involved in any decisions that affect the Sprint Goal and the Product Backlog. References:

• Scrum Guide, page 10: “If the work turns out to be different than the Developers expected, they collaborate with the Product Owner to negotiate the scope of Sprint Backlog within the Sprint.”
• Scrum Guide, page 11: “The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team.”

• In Scrum, there is only one product and one Product Backlog for a given product. The Product Backlog is the single source of truth for the Scrum Team and the stakeholders. It contains all the requirements, features, functions, enhancements, fixes, and anything else that can deliver value to the customers and users of the product. The Product Backlog is ordered by the Product Owner based on the product vision, goals, and value.
• Having multiple Product Backlogs for one product would create confusion, duplication, inconsistency, and waste. It would also make it harder to align the Scrum Teams and the stakeholders on the same product direction and priorities. Therefore, each Scrum Team should not have a separate Product Backlog.
• The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team. The Product Owner is responsible for managing and refining the Product Backlog, collaborating with the stakeholders and the Developers, and ordering the items in a way that best achieves goals and missions. The Product Owner represents the interests of everyone with a stake in the product and ensures that the Scrum Team works on the right things at the right time.
• Having multiple Product Owners for one product would create conflicts, overlaps, gaps, and inefficiencies. It would also make it harder to maintain a clear and consistent product vision, strategy, roadmap, and backlog. Therefore, there should be only one Product Owner for one product.
• In some cases, when there are multiple Scrum Teams working on one product, it may be necessary to have some form of scaling or coordination mechanism to ensure alignment and collaboration among the teams. However, this does not mean that there should be multiple Product Owners or Product Backlogs. Instead, there should be ways to facilitate communication, feedback, integration, and transparency among the teams and with the Product Owner. For example, some frameworks or practices that can help with scaling Scrum are Nexus, LeSS, SAFe, or Scrum of Scrums.

References:

• Scrum Guide: https://www.scrumguides.org/scrum-guide.html
• Nexus: https://www.scrum.org/resources/what-is-nexus
• LeSS: https://less.works/
• SAFe: https://www.scaledagileframework.com/
• Scrum of Scrums: https://www.agilealliance.org/glossary/scrum-of-scrums/