Scrum PSPO-I Professional Scrum Product Owner I Exam Practice Test

Answer : C

The ''cone of uncertainty'' is a graphical representation of the degree of uncertainty in a project estimate over time. It shows that the range of possible outcomes is wider at the beginning of the project and narrows down as the project progresses and more information becomes available.

The ''cone of uncertainty'' can be used to illustrate that as a project forecast lengthens, it is increasingly less certain. This means that the longer the time horizon for a project, the more variability and risk there is in the estimate. This also implies that shorter iterations and frequent feedback can help reduce uncertainty and improve accuracy.

The ''cone of uncertainty'' cannot be used to determine whether to cut quality, similar to the ''Iron Triangle'' of project management. The ''Iron Triangle'' is a model that shows the trade-offs between scope, time, and cost in a project. Quality is often considered as a fourth dimension that is affected by these three factors. Cutting quality is not a desirable option for any project, especially for Scrum projects that value delivering high-quality products that meet customer needs.

The ''cone of uncertainty'' cannot be used to determine the cost of a project before it begins. The cost of a project depends on many factors, such as the scope, the resources, the complexity, the risks, and the market conditions. The ''cone of uncertainty'' only shows the range of possible outcomes based on the available information at a given point in time. It does not provide a definitive or accurate estimate of the cost before the project starts.

The ''cone of uncertainty'' cannot be used to determine the length of the next Sprint. The length of the next Sprint is determined by the Scrum Team based on their empirical experience and their ability to deliver a potentially releasable Increment of value. The ''cone of uncertainty'' does not provide any guidance on how long a Sprint should be or how much work can be done in a Sprint.

Scrum Guide: https://www.scrumguides.org/scrum-guide.html

Cone of Uncertainty: https://www.agilealliance.org/glossary/cone-of-uncertainty/

Answer : D

The Scrum Team is a self-organizing and cross-functional team that delivers valuable products in an agile way. The Scrum Team consists of one Product Owner, one Scrum Master, and Developers. They are all accountable for creating a valuable, useful, and potentially releasable product Increment each Sprint.

The Scrum Team is responsible for making sure everyone on the Scrum Team does their tasks for the Sprint. The Scrum Team does not rely on any external authority, manager, or leader to assign or monitor their work. The Scrum Team collaborates and coordinates their work as one unit, without any hand-offs or silos. The Scrum Team also inspects and adapts their work based on empirical evidence and feedback.

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.

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 other options are not valid or relevant answers for who should make sure everyone on the Scrum Team does their tasks for the Sprint. They are either nonexistent or irrelevant roles in Scrum. They are:

The Project Manager: There is no ''Project Manager'' role in Scrum. Scrum is a framework for developing, delivering, and sustaining complex products, not projects. A project is a temporary endeavor with a fixed scope, time, and cost. A product is a valuable solution that evolves over time to meet customer needs and market conditions. A project manager is a role in traditional project management, a discipline for planning, executing, and controlling projects. A project manager coordinates and controls the activities of the project team and the stakeholders and ensures that the project meets the quality standards and expectations.

The Product Owner: The Product Owner is not responsible for making sure everyone on the Scrum Team does their tasks for the Sprint. The Product Owner is responsible for maximizing the value of the product resulting from the work of the Scrum Team. The Product Owner does not assign or monitor tasks to the Developers. The Product Owner collaborates with them to clarify and refine the Product Backlog items and their acceptance criteria.

All of the above: This is not a valid answer because it includes two invalid options: The Project Manager and The Product Owner.

Scrum Guide: https://www.scrumguides.org/scrum-guide.html

Scrum Team: https://www.scrum.org/resources/what-is-a-scrum-team

Product Owner: https://www.scrum.org/resources/what-is-a-product-owner

Developers: https://www.scrum.org/resources/what-is-a-developer-in-scrum

Scrum Master: https://www.scrum.org/resources/what-is-a-scrum-master

Answer : B

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

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

Answer : C, D, E

The advantages of a Product Owner sharing a clearly defined Product Goal with the Scrum Team are:

It provides a good overall direction so Sprints will feel less like isolated pieces of work. The Product Goal is a long-term objective for the product that guides all the activities of the Scrum Team. It helps the Scrum Team align their efforts and focus on delivering value that contributes to the product vision.

It helps the Scrum Team keep focus and they can weigh any decision against the Product Goal. The Product Goal serves as a filter for deciding what to work on and what not to work on. It helps the Scrum Team prioritize and optimize their work based on value and impact.

It is easier to inspect incremental progress at the Sprint Review. The Sprint Review is an event where the Scrum Team and the stakeholders collaborate on the product and inspect how it meets the Product Goal. The Increment is a concrete and usable outcome of the Sprint that provides a measure of progress towards the Product Goal.

Other options, such as helping the Developers estimate the date that the Product Backlog will be complete or being not mandatory in Scrum, are not valid advantages of having a Product Goal. They may reflect a misunderstanding of what a Product Goal is or how Scrum works.

[Scrum Guide], page 10, section ''Product Goal''

[Professional Scrum Product Owner Training], page 6, section ''Product Vision''

[Professional Scrum Product Owner Training], page 7, section ''Product Backlog Management''

[Scrum Guide], page 13, section ''Sprint Review''

[Scrum Guide], page 10, section ''Increment''

Answer : C

The timebox for the Sprint Review is four hours for a one-month Sprint. This is because:

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 timebox for each Scrum event is proportional to its frequency and duration. A one-month Sprint corresponds to a maximum calendar month.

The timebox for a one-month Sprint Review is four hours. For shorter Sprints, it is usually shorter.

The timebox ensures that there is enough time to inspect what has been done in relation to what could be done next and make any necessary adaptations to optimize value.

Other options, such as two hours for a one-month Sprint, one day, or as long as needed, are not valid answers as they do not reflect the correct timebox for the Sprint Review.

[Scrum Guide], page 17, section ''Sprint Review''

[Scrum Guide], page 9, section ''Sprint''

[Scrum Guide], page 9, section ''Timeboxing Scrum Events''

Answer : A, D

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 Developers. The Sprint Backlog is the set of Product Backlog items selected for the Sprint, plus a plan for delivering the product Increment and realizing the Sprint Goal1. The Developers are responsible for creating and maintaining the Sprint Backlog1. The Developers are not accountable for selecting the Product Owner, reporting productivity, or any other activities that are not related to creating a Done Increment that meets the Sprint Goal123. Reference:

Scrum Guide

What is a Developer?

Who Determines How Work Is Performed During The Sprint?

[What is Sprint Planning?]

Answer : B

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