Free Practice Questions for Scrum PSPO-I Exam

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.

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 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 creating and communicating a vision, ordering the Product Backlog, and ensuring that the best possible job is done to delight customers. The Product Owner does not manage the Developers, but collaborates with them and the Scrum Master to optimize the value delivery. The Product Owner does not ensure that the work meets the commitments to the stakeholders, but rather that the work delivers value to the stakeholders. The Product Owner does not keep stakeholders from distracting the Developers, but rather engages them and manages their expectations.

Professional Scrum Product Owner™ I Certification

[The Scrum Guide]

[The Product Owner]

The Developers are the people in the Scrum Team who are committed to creating any aspect of a usable Increment each Sprint. The Developers are accountable for organizing and managing their work.Only the Developers can decide how to perform the work during the Sprint1. The Developers plan the work necessary to create an Increment that meets the Definition of Done during the Sprint Planning event. This is often done by decomposing Product Backlog items into smaller work items of one day or less.How this is done is at the sole discretion of the Developers2.The Developers also inspect their progress toward the Sprint Goal and adapt their plan during the Daily Scrum1.The Developers are self-managing, which means they decide internally who does what, when, and how1. The Scrum Master, the Product Owner, the team manager, and the subject matter experts are not involved in determining how the work is performed during the Sprint.They may provide guidance, feedback, or support, but they do not interfere with the Developers’ autonomy and accountability134.References:

Scrum Guide

What is a Developer?

Who Determines How Work Is Performed During The Sprint?

What is Sprint Planning?

Transparency is one of the three pillars of Scrum, along with inspection and adaptation. Transparency means that all aspects of the Scrum process and the product are visible and understandable to everyone who needs to work on or with them. Transparency enables effective inspection and adaptation, which are essential for delivering valuable products and improving the Scrum Team’s performance.

All Scrum artifacts must be transparent to ensure sufficient accuracy of inspection. Scrum artifacts include the Product Backlog, the Sprint Backlog, and the Increment. The Product Backlog is an ordered list of everything that is known to be needed in the product. It 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.

Two measures that ensure that the Product Backlog is transparent are:

The Product Backlog is ordered: The Product Owner orders the items in the Product Backlog based on factors such as value, risk, priority, dependency, feedback, or market conditions. The order of the Product Backlog items provides a clear and consistent indication of what is most important and urgent for the product. The order of the Product Backlog items also helps the Scrum Team and the stakeholders to plan and forecast effectively.

The Product Backlog is available to all stakeholders: The Product Owner makes the Product Backlog visible and accessible to everyone who has a stake in the product, such as customers, users, sponsors, managers, or other teams. The availability of the Product Backlog enables transparency, collaboration, feedback, and alignment among all parties involved in the product development.

The other options are not valid or relevant measures to ensure that the Product Backlog is transparent. They are either too restrictive, arbitrary, or unrelated to the Product Backlog’s transparency. They are:

Each Product Backlog item has a MoSCoW priority: MoSCoW is a technique for prioritizing requirements based on their importance: Must have, Should have, Could have, or Won’t have. While this technique can be useful for some products or contexts, it is not a mandatory or universal way to order the Product Backlog items. The Product Owner may use other factors or methods to order the Product Backlog items based on their value and relevance for the product.

The Product Backlog only has work for the next 2 Sprints: This is a too limiting and unrealistic measure for the Product Backlog. The Product Backlog should contain all the work that is known to be needed in the product, not just for the next 2 Sprints. The Product Backlog is a living artifact that evolves as the product and the market change. The Product Owner should continuously refine and update the Product Backlog to reflect the current and future needs and expectations of the customers and users.

The Product Backlog is managed using a web-based tool: This is an irrelevant measure for the Product Backlog’s transparency. The Product Owner can use any tool or format to manage the Product Backlog, as long as it is clear, concise, and valuable. The tool or format does not affect the transparency of the Product Backlog itself. What matters more is how the Product Owner communicates and collaborates with the Scrum Team and the stakeholders using the Product Backlog.

The Sprint Retrospective is an event for the Scrum Team to inspect how the last Sprint went with regards to individuals, interactions, processes, tools, and their Definition of Done1. The purpose of the Sprint Retrospective is to plan ways to increase quality and effectiveness for the next Sprint2. Therefore, appropriate topics for discussion during a Sprint Retrospective are:

Identifying high priority process improvements for the next Sprint. The Scrum Team should identify the most important things that went well and the potential improvements, and create a plan for implementing some of them in the next Sprint[3][3] . This way, the Scrum Team can continuously improve their performance and deliver more value.

How the team collaborates. The Scrum Team should reflect on how they work together as a self-managing unit, and how they can enhance their skills, tools, and relationships4. This way, the Scrum Team can foster a culture of trust, respect, and collaboration.

The other options are not appropriate topics for discussion during a Sprint Retrospective, as they are either related to the Product Backlog or the Sprint Backlog, which are not the focus of the Sprint Retrospective. The order of items in the Product Backlog is the responsibility of the Product Owner, who manages the Product Backlog based on the value, risk, and dependencies of the items5. The Product Owner may seek input from the Scrum Team or the stakeholders, but the final decision is up to the Product Owner. Documenting acceptance criteria for items in the next Sprint is part of the Product Backlog refinement, which is an ongoing activity throughout the Sprint, not a specific event. The Scrum Team should collaborate on refining the Product Backlog items and adding more details, such as acceptance criteria, as they become more clear and ready for selection in a Sprint Planning.

The best approach for Scrum Teams to produce valuable Increments is to be accountable for developing functionality from beginning to end, as this enables them to deliver potentially releasable products that meet the definition of “Done”. 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 This means that the Developers are not limited by the boundaries of components, layers, or technologies, but rather they collaborate and coordinate to deliver a complete and integrated product that satisfies the Sprint Goal and the Product Owner’s expectations.

1: The Scrum Guide2, page 7

2: The Scrum Guide

 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.

Multiple Scrum Teams working on the same product do not have to have the same Sprint start date. The Scrum Guide does not prescribe any synchronization of Sprints across multiple teams1. However, it is recommended that the teams align their Sprint cadence and duration, and coordinate their dependencies and integration through a shared Product Backlog, a common Definition of Done, and frequent communication2. This way, the teams can deliver a coherent and valuable product Increment every Sprint[3][3] .

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.