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

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.

The Scrum Guide

Understanding and Applying the Scrum Framework

Professional Scrum Product Owner™ I Certification

Non-functional requirements are the criteria that define the quality, performance, security, usability, and other aspects of a product1. They are often implicit or assumed, but they are important to make visible and explicit, as they affect the value and satisfaction of the product2. One effective way to make non-functional requirements visible is to add them to the Product Backlog, which is an ordered list of everything that is known to be needed in the product[3][3] . By adding non-functional requirements to the Product Backlog, the Product Owner and the Developers can prioritize, refine, and estimate them, and make them transparent to the stakeholders4. Another effective way to make non-functional requirements visible is to add them to the Definition of Done, which is a shared understanding of what it means for work to be complete, and ensures transparency of the quality of the work done5. By adding non-functional requirements to the Definition of Done, the Developers can ensure that every Product Backlog item and Increment meets the expected quality standards, and that the work is taken care of every Sprint.

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.org2:What is a Product Backlog? | Scrum.org

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.

The Product Owner is accountable for ordering the Product Backlog. 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 tools and techniques used to create, manage, or refine the Product Backlog are not a valid consideration when ordering the Product Backlog. The tools and techniques are means to an end, not an end in themselves. The tools and techniques do not affect the value or quality of the product or service delivered. The tools and techniques may vary from one Product Owner to another, depending on their preferences, skills, or context. The tools and techniques may also change over time, as new technologies or practices emerge or evolve.

The amount of the Sprint Backlog that must be defined during the Sprint Planning event is enough so the Developers can create their forecast of what work they can do. 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 Developers are accountable for creating a Sprint forecast, which is a selection of Product Backlog items that they intend to work on during the Sprint. The Sprint forecast should be realistic, achievable, and valuable.

The Developers are also accountable for creating a plan for how they will deliver the selected Product Backlog items as a “Done” Increment. The plan may include tasks, dependencies, risks, estimates, or other information that helps them organize and manage their work.

The amount of the Sprint Backlog that must be defined during Sprint Planning may vary depending on the context, complexity, and uncertainty of the product development. However, it should be enough so that the Developers can create their forecast of what work they can do and have a clear direction for the first few days of the Sprint.

Other options, such as just enough to understand design and architectural implications, the entire Sprint Backlog being identified and estimated by the end of Sprint Planning, or just enough tasks for the Scrum Master to be confident in the Developers’ understanding of the Sprint, are not valid answers as they do not reflect what must be defined during Sprint Planning or what is required for creating a Sprint forecast.

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.

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 Guide states that " The Daily Scrum is a 15-minute time-boxed event for the Development Team to synchronize activities and create a plan for the next 24 hours. " 1 The Daily Scrum is a quick and simple planning meeting designed to keep everyone in the loop with how other team members are getting on. It ensures that team members are fully aligned with each other and on track to hit the Sprint Goal.

1: The Scrum Guide2, page 11

2: The Scrum Guide

Correct Answer: True

Dependencies are relationships between Product Backlog items that affect their order of implementation. For example, a Product Backlog item may depend on another one to be completed first, or it may have a dependency on a third-party system or resource. Dependencies could influence how the Product Owner orders Product Backlogitems, as they may introduce risks, constraints, or uncertainties that affect the value delivery. The Product Owner should try to minimize dependencies and order the Product Backlog items in a way that maximizes value and minimizes waste.

[Professional Scrum Product Owner], chapter 6: “Dependencies are relationships between Product Backlog items that affect their order of implementation.”

[Managing Dependencies on Agile Projects]: “Dependencies can have a significant impact on the delivery of value.”

The Daily Scrum is an event for and by the Developers.They can choose whatever structure and technique they want, as long as they focus on the progress toward the Sprint Goal and produce an actionable plan for the next day of work12. The Scrum Master, the Product Owner, and the person coming in last are not necessarily the ones who should start the Daily Scrum.The person who has the token is a possible technique, but not the only one3.