Free Scrum PSPO-I Practice Exam with Questions & Answers | Set: 4

The Product Owner does not make sure the Developers select enough from the Product Backlog for a Sprint. The Product Owner is responsible for maximizing the value of the product and the work of the Developers, but the Developers are self-managing and decide how much work they can do in a Sprint1. The Product Owner and the Developers collaborate on the scope of the Sprint during Sprint Planning, but the final decision is up to the Developers2. The Product Owner should not interfere with the Developers’ work during the Sprint, but should provide feedback and guidance on the product value[3][3].

References:

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

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

[3][3]: Professional Scrum Product Owner I Certification, Scrum.org, accessed on December 16, 2023

The Sprint Goal is a short statement that gives the Sprint a purpose, direction, and focus. It is created by the entire Scrum Team during Sprint Planning, based on the Product Owner’s draft and the Developers’ input. The Sprint Goal is then added to the Sprint Backlog and guides the Developers’ work during the Sprint.

References:

• What is a Sprint Goal?
• The Sprint Goal
• How to Write and Use a Sprint Goal (With 5 Templates)

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

• 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, a Product Owner with multiple teams working on one product should not maintain separate Product Backlogs for each team.
• 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.
• 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: [1]
• LeSS: [2]
• SAFe: [3]
• Scrum of Scrums: [4]

The Scrum Team consists of one Scrum Master, one Product Owner, and Developers. Within a Scrum Team, there are no sub-teams or hierarchies. It is a cohesive unit of professionals focused on one objective at a time, the Product Goal. The Scrum Master is accountable for establishing Scrum as defined in the Scrum Guide. They do this by helping everyone understand Scrum theory and practice, both within the Scrum Team and the organization. The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team. They are responsible for creating and communicating a vision, ordering the Product Backlog, and ensuring that the best possible job is done to delight customers. The Developers are the people in the Scrum Team that are committed to delivering a “Done” Increment that meets the Definition of Done and the Sprint Goal. They are responsible for managing and organizing their work within the Sprint, collaborating with the Product Owner and the Scrum Master, and applying their skills and creativity to create a product that delivers value to the stakeholders and customers. A Project Manager is not a role in the Scrum Team, as Scrum does not recognize titles for Developers, regardless of the work being performed by the person. There is no need for a Project Manager, as the Scrum Team is self-managing and accountable for delivering value.

References:

• The Scrum Guide
• The Scrum Team
• Professional Scrum Product Owner™ I Certification

The Developers are the ones who determine how many Product Backlog items they select for a Sprint. The Developers are self-managing and decide how much work they can do in a Sprint1. The Product Owner and the Developers collaborate on the scope of the Sprint during Sprint Planning, but the final decision is up to the Developers2. The Product Owner, the Scrum Master, and the stakeholders do not have the authority to tell the Developers how many Product Backlog items they should select, as this would violate the principle of self-management[3][3].

References:

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

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

[3][3]: Understanding and Applying the Scrum Framework, Scrum.org, accessed on December 16, 2023

 An Increment is the sum of all the Product Backlog items completed during a Sprint and the value of the increments of all previous Sprints.1 An Increment is a concrete, tangible, and usable outcome of the work done by the Developers in a Sprint. It is not a plan, a mock-up, a design, or a roll-out plan, as these are not valuable or useful products in themselves. An Increment must meet the definition of “Done”, which means it must adhere to the quality standards agreed upon by the Scrum Team and the stakeholders.1 An Increment must also be potentially releasable, which means it must be in a state that it could be delivered to the customer or user if the Product Owner decides so.1

References:

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

The Scrum Guide states that "Sprints have consistent durations throughout a development effort. A new Sprint starts immediately after the conclusion of the previous Sprint."1 This means that there is no gap or break between Sprints, and the Scrum Team does not need to spend extra time to prepare for the next Sprint. The Scrum Team should be able to start the next Sprint Planning right after the Sprint Review and Sprint Retrospective of the previous Sprint. The Scrum Team should also ensure that the testing and documentation of the work are done within the Sprint, and not left for later.

References:

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

To say that an event has a timebox means that the event has a fixed duration that cannot be exceeded. The Scrum Guide states that "All events are time-boxed events, such that every event has a maximum duration. Once a Sprint begins, its duration is fixed and cannot be shortened or lengthened. The remaining events may end whenever the purpose of the event is achieved, ensuring an appropriate amount of time is spent without allowing waste in the process."1 This means that the timebox sets an upper limit for the event, but the event can end sooner if the goal is met.

References:

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

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

References:

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

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

[3][3]: Understanding and Applying the Scrum Framework, Scrum.org, accessed on December 16, 2023