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

If the Developers find out during the Sprint that they are not likely to build everything they forecast, the best response from the Product Owner is to re-work the selected Product Backlog items with the Developers to meet the Sprint Goal. This is because:

The Sprint Goal is a short-term objective that provides guidance and focus to the Scrum Team throughout the Sprint. It is a flexible and negotiable commitment that can be adjusted as more is learned throughout the Sprint.

The Developers are accountable for creating a “Done” Increment in every Sprint. They must ensure that every Product Backlog item they work on meets the Definition of Done before it is considered complete.

The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team. They must inspect the Increment at the end of each Sprint and assess how it delivers value and contributes to the Product Goal.

The Product Owner and the Developers must collaborate closely throughout the Sprint to ensure that they have a shared understanding of what they are building and why. The Product Owner must provide clarifications, feedback, and guidance to the Developers as needed to help them create a valuable Increment.

If the Developers find out during the Sprint that they are not likely to build everything they forecast, it means that there is a gap between their initial plan and their actual progress. This may happen due to various reasons, such as new insights, changing requirements, technical challenges, or unforeseen circumstances.

In this situation, the Product Owner should work with the Developers to re-work the selected Product Backlog items to meet the Sprint Goal. This may involve adding, removing, or modifying some items, as long as they still support the Sprint Goal and deliver value. The Product Owner should also communicate any changes or impacts to the stakeholders and customers as appropriate.

Other options, such as skipping Product Backlog refinement activities, informing management that more Developers are needed, changing the Sprint Goal, or canceling the Sprint, are not valid responses from the Product Owner as they do not reflect what should happen in Scrum or how to deal with uncertainty and complexity.

The Developers are accountable for managing the progress of work during a Sprint, as they are the ones who plan, execute, and deliver the work. 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 The Developers are also responsible for conducting the Daily Scrum, a 15-minute event for the Developers to synchronize activities and create a plan for the next 24 hours.1 The Developers are self-managing, which means they decide how best to accomplish their work, rather than being directed by others outside the Scrum Team.1

1: The Scrum Guide2, page 7

2: The Scrum Guide

An Increment is a concrete stepping stone toward the product vision. It is the sum of all the Product Backlog items completed during a Sprint and the value of the increments of all previous Sprints. At the end of a Sprint, the new Increment must be “Done”, which means it meets the Definition of Done and is usable.

The Scrum Team decides when and how to release an Increment to customers or users. The Product Owner is responsible for maximizing the value of the product and the work of the Developers, and may decide to release an Increment at any time during or after a Sprint. The Developers are responsible for creating a potentially releasable Increment each Sprint, and may collaborate with the Product Owner and the stakeholders to determine the best way to deliver value.

Releasing an Increment to customers or users is not mandatory at the end of each Sprint. The Scrum Team may choose to release an Increment more or less frequently, depending on the product goals, market conditions, customer feedback, or technical feasibility. However, releasing an Increment regularly can provide many benefits, such as:

Validating assumptions and hypotheses about the product value and quality.

Obtaining feedback and data from real users and customers.

Increasing customer satisfaction and loyalty.

Reducing risks and uncertainties.

Improving transparency and collaboration.

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.

The Developers 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.

A Sprint is a timebox of one month or less within which a “Done” product Increment is created. A Sprint consists of the Sprint Planning, Daily Scrums, the development work, the Sprint Review, and the Sprint Retrospective. A Sprint is also a feedback loop that allows the Scrum Team and the stakeholders to inspect and adapt the product and the process.

The Sprint Goal is a short statement of what the Scrum Team intends to achieve during a Sprint. It provides guidance and direction for the Scrum Team, as well as a basis for inspecting and adapting the product and the process. The Sprint Goal is aligned with the product vision and goals, and it reflects the value and purpose of the Sprint.

In the middle of a Sprint, if a customer decides that there are two new features she wants, there are two possible ways that a Product Owner could handle this situation:

Ask the Developers to consider whether they can add these features to the current Sprint without endangering the Sprint Goal: The Product Owner could discuss with the Developers if they have enough capacity and skills to accommodate these new features in their current Sprint Backlog. The Product Owner could also explain why these features are valuable or urgent for the customer or user. The Developers could then decide if they can or want to add these features to their current work plan, or if they prefer to defer them to a future Sprint. The Developers should not compromise on quality or scope to fit these features in their current Sprint. The Developers should also ensure that these features are aligned with or support the current Sprint Goal.

Add these features to the Product Backlog: The Product Owner could add these new features to the Product Backlog as new items. The Product Owner could then order these items based on their value, risk, priority, dependency, feedback, or market conditions. The Product Owner could also refine these items with more details or acceptance criteria. The Product Owner could then plan to include these items in a future Sprint, depending on their order and availability.

The other options are not valid or relevant ways that a Product Owner could handle this situation. They are either too disruptive, impractical, or irrelevant. They are:

Introduce these features at the next Daily Scrum: This is not a valid way for a Product Owner to handle this situation. The Daily Scrum is an event for the Developers to inspect their progress toward the Sprint Goal and adapt their plan for the next 24 hours. The Daily Scrum is not a status meeting or a reporting session for anyone else. The Product Owner may attend the Daily Scrum as an observer or as an invited participant if they have something valuable to contribute or if they need some clarification from the Developers. However, introducing new features at this event would be disruptive and inappropriate for both parties.

Have the Scrum Master add these features to the current Sprint: This is not a valid way for a Product Owner to handle this situation. The Scrum Master is not responsible for adding or removing any work from the current Sprint. The Scrum Master is accountable for establishing Scrum as defined in the Scrum Guide. The Scrum Master is responsible for promoting and supporting Scrum as defined in the Scrum Guide. The Scrum Master does this by helping everyone understand Scrum theory and practice, both within the Scrum Team and the organization.

the first Sprint is the same as any other Sprint, and the Scrum Team should deliver a potentially releasable Increment of " Done " product at its conclusion. This means that the team should build at least one piece of valuable functionality that meets the Definition of Done and aligns with the Sprint Goal. The other options are not things that the Scrum Team should do during the first Sprint, as they are either too detailed, too vague, or too long-term for the Scrum framework.The Scrum Team should not make up a plan for the rest of the project, as Scrum is an empirical process that adapts to changing requirements and feedback1.The Scrum Team should not define the major product features and a release plan architecture, as these are the responsibilities of the Product Owner, who should have a vision and a roadmap for the product2.The Scrum Team should not analyze, describe, and document the requirements for the subsequent Sprints, as this would violate the principle of emergent design and just-in-time planning3.

1:The Scrum Guide | Scrum.org2:What is a Product Owner? | Scrum.org3:Emergent Design and Just-in-Time Planning | Scrum.org

According to the Scrum Guide1, the Developers are responsible for selecting the amount of work they can do in a Sprint, based on their capacity and past performance2. If they realize that the workload may be greater than their capacity, they can either remove or change some of the selected Product Backlog items, or they can start the Sprint and monitor the progress, making adjustments as needed3. Recruiting additional Developers, canceling the Sprint, or working overtime are not valid actions, as they would disrupt the Scrum values of commitment, focus, and respect

In Scrum, the Product Owner is responsible for maximizing the value of the product resulting from the work of the Development Team. One of the primary ways the Product Owner does this is by managing the Product Backlog, which includes clearly expressing Product Backlog items, ordering the items to best achieve goals and missions, and ensuring that the Product Backlog is visible, transparent, and clear to all. This means that the Product Owner has the final authority on the order of items in the Product Backlog, as they are best positioned to understand the strategic and market value of the work to be done.

The Scrum Guide and the Professional Scrum Product Owner™ (PSPO I) study materials, specifically the sections on ‘Managing Products with Agility’ and ‘Understanding and Applying the Scrum Framework’, which outline the accountabilities of the Product Owner in managing the Product Backlog

 A Product Owner should not measure product value by the increase in the team’s velocity. This is because:

Velocity is a measure of how much work a Scrum Team can deliver in a Sprint. It is based on the estimation of Product Backlog items that are selected for a Sprint and completed according to the Definition of Done.

Velocity is not a measure of product value. It does not reflect how well the product meets the needs and expectations of the customers, users, and stakeholders. It does not reflect how much value or impact the product creates in terms of revenue, satisfaction, or social good.

Velocity is not a goal or a target for a Scrum Team. It is a planning tool that helps them forecast their future work based on their past performance. It is not a metric that should be used to compare or judge teams or individuals.

A Product Owner should measure product value by using indicators that are relevant, meaningful, and actionable for their product context. These may include metrics such as customer feedback, usage data, market share, return on investment, or social impact.

 When there are multiple teams working on one product, each Scrum Team should not have a separate Product Owner. This is because:

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 the sole person responsible for managing the Product Backlog, which is an emergent, ordered list of what is needed to improve the product. They must ensure that the Product Backlog is transparent, visible, and understood by everyone who needs to work on it.

Having multiple Product Owners for one product may lead to conflicts, inconsistencies, or confusion among the Scrum Teams and the stakeholders. It may also reduce the alignment, collaboration, and ownership of the product development.

Instead of having multiple Product Owners, it is recommended to have one Product Owner who works with representatives from each Scrum Team to ensure that they have a shared understanding of the product vision, goals, and priorities. The Product Owner may also delegate some of the Product Backlog management tasks to these representatives, but they remain accountable for the final decisions.

Answer: False

Very Short Explanation: According to Scrum.org, the Product Owner is not required to create clear and unambiguous acceptance criteria for each item in the product’s backlog before it can be selected in Sprint Planning1.Acceptance Criteria is optional and is not prescribed by Scrum12.It can be valuable, but it’s not a must12.The Developers can inspect and adapt the Sprint Backlog in any way they see fit, in order to help meet the Sprint Goal2.