Most Recent Scrum PSPO-I Exam Questions & Answers

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/

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.

[Scrum Guide], page 7, section ''Developers''

[Scrum Guide], page 10, section ''Definition of Done''

[Scrum Guide], page 15, section ''Sprint Backlog''

[Professional Scrum Product Owner Training], page 5, section ''Product Value''

[Professional Scrum Product Owner Training], page 9, section ''Business Strategy''

During the Sprint Retrospective, the Scrum Team discusses how the last Sprint went with regards to individuals, interactions, processes, tools, and their Definition of Done123. This includes methods of communication, the way the Scrum Team does Sprint Planning, skills needed to improve the Developers' ability to deliver, and the Definition of Done123.

Correct Answers : A, C, and D .

The Sprint Retrospective is an event where the Scrum Team reflects on how they worked together in the last Sprint and identifies ways to improve their collaboration, processes, and quality. Therefore, appropriate topics for discussion in a Sprint Retrospective are:

Team relations: The Scrum Team should discuss how they communicated, interacted, and supported each other during the Sprint. They should celebrate their successes, acknowledge their challenges, and address any conflicts or issues that arose. They should also share feedback, appreciation, and suggestions for improvement with each other.

How the Scrum Team does its work: The Scrum Team should inspect the methods, tools, and practices they used to deliver the product increment. They should evaluate what worked well and what could be improved. They should also identify any impediments, risks, or dependencies that affected their work and how they handled them.

Definition of Done: The Scrum Team should review their Definition of Done and check if it is still relevant, clear, and achievable. They should also assess how well they adhered to it and if they delivered a potentially releasable product increment that meets the quality standards. They should also consider if they need to update or adapt their Definition of Done based on new insights or feedback.

The following topics are not appropriate for discussion in a Sprint Retrospective:

The value of work currently represented in the Product Backlog: The value of the Product Backlog items is the responsibility of the Product Owner, who should continuously refine and order them based on stakeholder needs and feedback. The value of the Product Backlog items is not directly related to how the Scrum Team works together and does not affect their improvement actions for the next Sprint.

Arranging the Sprint Backlog for the next Sprint: The Sprint Backlog is the plan for the next Sprint that is created by the Scrum Team during the Sprint Planning event. The Sprint Backlog is based on the Product Backlog items that are selected for the next Sprint and how the Developers intend to accomplish them. The Sprint Retrospective is not a planning event but a reflection event that focuses on the past Sprint.

[Scrum Guide], section 3.5: ''The purpose of the Sprint Retrospective is to plan ways to increase quality and effectiveness.''

[Professional Scrum Product Owner], chapter 7: ''The Sprint Retrospective is an opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint.''

What is a Sprint Retrospective? | Scrum.org: ''During each Sprint Retrospective, the Scrum Team plans ways to increase product quality by improving work processes or adapting the definition of ''Done'' if appropriate and not in conflict with product or organizational standards.''

The Sprint Retrospective - What It Is & Tips for Making the Most of Your Meeting: ''The focus is on how the team worked together in the last sprint, including: Communication Teamwork Process Tools Systems Work environment Missing competencies Collaboration with external parties''

Sprint Planning is an event where the Scrum Team collaborates on the work to be performed during the Sprint1. The topics covered in Sprint Planning are:

What can be done. The Product Owner proposes how the product could increase its value and utility in the current Sprint, based on the Product Goal, the Product Backlog, and the latest market and stakeholder feedback. The Developers assess the capacity and the technical feasibility of the work, and select the Product Backlog items that they can commit to for the Sprint.The Scrum Team crafts the Sprint Goal, which is a concise statement of the purpose and focus of the Sprint2.

How to do it. The Developers plan how they will deliver a ''Done'' product Increment that meets the Sprint Goal. They create a plan for the first days of the Sprint, and decompose the selected Product Backlog items into smaller work items. The Developers also identify any dependencies, risks, or impediments that may affect their work. The resulting plan is captured in the Sprint Backlog, which is owned and managed by the Developers[3][3].

Why to do it. The Product Owner explains the value and the outcome of the work to be done in the Sprint, and how it aligns with the Product Goal and the stakeholder needs. The Product Owner also clarifies the acceptance criteria and the Definition of Done for the Product Backlog items, and answers any questions from the Developers.The Scrum Team ensures that they have a common understanding of the Sprint Goal and the expected product Increment4.

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

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

[3][3]:The Scrum Guide, November 2020, p. 10

4:Understanding and Applying the Scrum Framework, Scrum.org, accessed on December 16, 2023