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

The Scrum Team includes skilled individuals who together have all the skills necessary to create value each Sprint.

According to the Scrum Guide1, “Scrum Teams are cross-functional, meaning the members have all the skills necessary to create value each Sprint.” This implies that the team does not depend on external resources or specialists to deliver a product increment. The other options do not reflect the true meaning of cross-functionality in Scrum.

1:The Scrum Team | Scrum.org

The Developers are the people in the Scrum Team who 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 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 amount of work required of the Developers to complete a Product Backlog item selected during the Sprint Planning depends on the Definition of Done. 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.

The Developers must ensure that each Product Backlog item they complete during a Sprint meets the Definition of Done. This means that they must perform all the necessary tasks and activities to deliver a high-quality product functionality that is usable, valuable, and potentially releasable. This may include analysis, design, development, testing, documentation, integration, deployment, or any other aspects that contribute to the quality and usability of the product.

The other options are not valid or relevant measures for the amount of work required of the Developers to complete a Product Backlog item. They are either too vague, arbitrary, or unrealistic. They are:

As much as they can fit into the Sprint, with remaining work deferred to the next Sprint: This is a too vague and unrealistic measure for the amount of work required of the Developers. It does not account for the quality or value of the product functionality delivered. It also does not respect the timebox or scope of the Sprint. It may lead to incomplete or unfinished work, technical debt, or scope creep.

All development work and at least some testing: This is a too arbitrary and insufficient measure for the amount of work required of the Developers. It does not account for the quality or value of the product functionality delivered. It also does not respect the Definition of Done or the potentially releasable nature of the Increment. It may lead to low-quality or unusable work, defects, or rework.

A proportional amount of time on analysis, design, development, and testing: This is a too restrictive and prescriptive measure for the amount of work required of the Developers. It does not account for the complexity or variability of the product functionality delivered. It also does not respect the self-organization or cross-functionality of the Developers. It may lead to over-engineering or waste.

The concept of a “Release Sprint” is not found in the Scrum Guide or the Professional Scrum Product Owner™ (PSPO I) materials. Scrum does not require a separate Sprint for releasing an Increment. According to Scrum, each Increment must be usable and potentially releasable at the end of every Sprint, which means the product should be in a releasable state irrespective of whether the Product Owner decides to release it or not. The idea of a Release Sprint is not aligned with Scrum’s principle of continuous delivery and the definition of “Done”.

The Scrum Guide and the Professional Scrum Product Owner™ (PSPO I) study materials emphasize the importance of the Increment being releasable after every Sprint without the need for an additional Release Sprint12.

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.

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.

 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.

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.

It is not true that the Product Owner makes sure the correct stakeholders are invited to the Sprint Retrospective. They might have important instructions for team improvements. This is because:

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 Sprint Retrospective is an internal event for the Scrum Team only. It is a safe and confidential space where the Scrum Team can openly and honestly reflect on their strengths and weaknesses, and identify actions to improve their performance and collaboration.

The stakeholders are not invited to the Sprint Retrospective. They do not have a say in how the Scrum Team works or what they should improve. The stakeholders can provide feedback and suggestions to the Scrum Team in other events, such as the Sprint Review or the Product Backlog refinement sessions.

The Product Owner is a member of the Scrum Team who 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 does not make sure the correct stakeholders are invited to the Sprint Retrospective. They might have important instructions for team improvements. This would violate the self-management and autonomy of the Scrum Team and undermine their trust and empowerment.

Sprints are fixed-length events of one month or less that serve as a container for the other Scrum events and activities. Sprints have consistent durations throughout a development effort. A new Sprint starts immediately after the conclusion of the previous Sprint. There is no gap or downtime between Sprints. The second Sprint starts right after the first Sprint, regardless of the customer acceptance testing, the architectural changes, or the Product Backlog items.

The Scrum Guide

Understanding and Applying the Scrum Framework

Professional Scrum Product Owner™ I Certification

The Daily Scrum is a 15-minute event for the Developers to synchronize activities and create a plan for the next 24 hours. This meeting is designed to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary. The intended outcomes are to identify any impediments that may prevent the Developers from achieving the Sprint Goal (D) and to foster a shared understanding among the Developers of what work is most important to undertake next in order to make the best possible progress toward the Sprint Goal (E). It is not a status update meeting for the Scrum Master or upper management, nor is it primarily about updating Scrum boards for stakeholder transparency.

The Scrum Guide and the resources provided by Scrum.org on the Daily Scrum emphasize these outcomes as essential to the effectiveness of the Daily Scrum event12.