Pass the Scrum PSPO PSPO-I Questions and answers with ExamsMirror

 A Scrum Team is required to deliver a done Increment by the end of a Sprint. Done means:

No work is left to meet the Definition of Done. 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 it means for work to be complete. It may include criteria such as coding standards, testing, documentation, security, performance, etc. If a Product Backlog item or an Increment does not meet the Definition of Done, it cannot be released or presented at the Sprint Review.

Ready to be released to end users. The Increment is a concrete output of the Sprint that adds value to the product. It is a potentially releasable functionality that adheres to the Scrum Team’s current Definition of Done. It is not necessarily released at the end of each Sprint, but it must be in a state that allows for immediate release if the Product Owner decides so. The Increment should also align with the Sprint Goal and the Product Goal, and satisfy the needs and expectations of the customers and stakeholders.

References:

Scrum Guide 2020, page 10: “The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product.”

Scrum Guide 2020, page 10: “The moment a Product Backlog item meets the Definition of Done, an Increment is born.”

Scrum Guide 2020, page 14: “The purpose of each Sprint is to deliver Increments of potentially releasable functionality that adhere to the Scrum Team’s current Definition of Done.”

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 Developers are the ones who are accountable for tracking the remaining work toward the Sprint Goal. The Developers are self-managing and decide how much work they can do in a Sprint1. They also create and update the Sprint Backlog, which is the plan for how the Developers will achieve the Sprint Goal, and the single source of truth for the work to be done in the Sprint2. The Developers use the Daily Scrum to inspect their progress toward the Sprint Goal and adapt the Sprint Backlog as necessary[3][3]. The Product Owner, the Scrum Master, and the Project Manager (if any) do not have the accountability for tracking the remaining work toward the Sprint Goal, as this is the responsibility of the Developers.

References:

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

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

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

 It is not true that the Product Owner must write all of the Product Backlog items (e.g. user stories, requirements, etc.) on the Product Backlog before handing them over to the Scrum Team. This is because:

The Product Backlog is an emergent, ordered list of what is needed to improve the product. It is never complete and constantly changes to reflect the needs and desires of the customers, users, and stakeholders.

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.

The Product Owner is also accountable for managing the Product Backlog items effectively. They must ensure that they are transparent, visible, and understood by everyone who needs to work on them. They must also collaborate with the Developers and stakeholders to refine, order, and prioritize them based on value and impact.

The Product Owner does not need to write all of the Product Backlog items by themselves or before handing them over to the Scrum Team. They can involve others in creating or contributing to them, such as customers, users, stakeholders, or Developers. They can also add or modify them at any time during the product development process, as long as they are clear and ready for selection in Sprint Planning.

References:

[Scrum Guide], page 6, section “Product Owner”

[Scrum Guide], page 11, section “Product Backlog”

[Scrum Guide], page 10, section “Product Goal”

[Scrum Guide], page 12, section “Product Backlog Refinement”

[Scrum Guide], page 14, section “Sprint Planning”

If the Scrum Team cannot complete its work by the end of the Sprint, the Sprint does not get extended. Instead, the unfinished Sprint Backlog Items go back to the Product Backlog and can be addressed in the following Sprint12. This approach allows the team to get better at estimating and reduces complexity due to the consistency of the Scrum Events2. The Scrum Team continuously learns and adapts12.

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 Sprint Retrospective is a time-boxed event for the Scrum Team to inspect how the last Sprint went and plan for improvements in the next Sprint. The Scrum Guide states that "The Sprint Retrospective concludes the Sprint. It is timeboxed to a maximum of three hours for a one-month Sprint. For shorter Sprints, the event is usually shorter."1 This means that the Sprint Retrospective should be held at the end of each Sprint, regardless of the project or release status. The Sprint Retrospective is an opportunity for the Scrum Team to inspect itself and create a plan for improvements, including to product quality and working relationships.1

References:

1: The Scrum Guide2, page 16

2: The Scrum Guide

The Product Owner is the sole person responsible for managing the Product Backlog and ensuring that the value of the work the Scrum Team performs is understood by everyone involved. The Product Owner is the only person who can cancel the Sprint, although he or she may do so under influence from the stakeholders, the Development Team, or the Scrum Master1. A Sprint can be cancelled before the Sprint time-box is over. Only the Product Owner has the authority to cancel the Sprint, although he or she may do so under influence from the stakeholders, the Development Team, or the Scrum Master. A Sprint would be cancelled if the Sprint Goal becomes obsolete. This might occur if the company changes direction or if market or technology conditions change. In general, a Sprint should be cancelled if it no longer makes sense given the circumstances. But, due to the short duration of Sprints, cancellation rarely makes sense1. References:

Scrum Guide

Sprint Cancellation

Can Scrum Master cancel a sprint?

It is not true that a Product Owner must create clear and unambiguous acceptance criteria for each Product Backlog item before it may be selected in Sprint Planning. This is because:

Acceptance criteria are a set of conditions that a Product Backlog item must satisfy to be accepted by the Product Owner or the stakeholders. They are used to verify that the item meets the expected quality and value standards.

Acceptance criteria are not mandatory or prescribed in Scrum. They are one of the possible techniques that a Product Owner may use to communicate their expectations and requirements to the Developers and the stakeholders. They are not part of the Scrum Guide or the Definition of Done.

Acceptance criteria do not need to be created before Sprint Planning. They can be created or refined at any time during the product development process, as long as they are clear and agreed upon before the item is considered complete. They can also be changed or updated based on feedback or new insights.

The only requirement for a Product Backlog item to be selected in Sprint Planning is that it is sufficiently clear and ready for selection. This means that it has enough detail and precision for the Developers to understand what they are supposed to build and why. It also means that it has been refined and ordered by the Product Owner based on value and impact.

References:

[Scrum Guide], page 14, section “Sprint Planning”

[Scrum Guide], page 12, section “Product Backlog Refinement”

[Professional Scrum Product Owner™ Training], page 7, section “Product Backlog Management”

According to Scrum.org, when splitting a large group into multiple Scrum Teams, it can be beneficial to allow the people to self-organize into smaller teams12. This approach respects the principle of self-organization, which is a key aspect of Scrum12. It allows individuals to choose the team they feel they can contribute to most effectively12. However, it’s important to note that this process should be facilitated and guided to ensure a balanced distribution of skills and capabilities across the teams12.