Free Scrum Professional Scrum Master I PSM-I Exam Questions

The correct answer is A, because the Scrum Guide states that ''a Sprint can be cancelled before the Sprint time-box is over. Only the Product Owner has the authority to cancel the Sprint, although he or she may do so under influence from the stakeholders, the Development Team, or the Scrum Master.'' Therefore, a Development Team cannot cancel a Sprint by itself.

The correct answer is B, because the Development Team determines how work is performed during the Sprint. The Scrum Guide states that ''development Teams are self-organizing. No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality.'' Therefore, the Development Team has the autonomy and responsibility to organize and manage its own work.

The correct answer is A because the Sprint Backlog is created during Sprint Planning. The Sprint Backlog is composed of the Sprint Goal, the Product Backlog items selected for the Sprint, and a plan for delivering them. During Sprint Planning, the Scrum Team collaborates to decide why the Sprint is valuable, what can be done during the Sprint, and how the chosen work will be accomplished. This is when the Sprint Backlog comes into existence.

Option B is incorrect because although Product Backlog refinement may prepare items before Sprint Planning, the Sprint Backlog itself is not created until the Sprint Planning event. Option C is incorrect because refinement supports readiness and clarity of Product Backlog items, but it does not establish the Sprint Backlog. Option D is incorrect because the Sprint Retrospective is focused on improvement of the team's effectiveness and ways of working, not on creating the Sprint Backlog for the next Sprint.

This distinction matters in Scrum because Sprint Planning formally begins the Sprint by creating a clear commitment around the Sprint Goal and the work needed to produce a useful Increment.

According to the Scrum Guide, three behaviors that demonstrate that a team is self-organizing are creating their own sprint backlog, having all the skills needed to create a releasable Increment, and collaboratively selecting their own work during the Sprint. The other options are not behaviors that demonstrate self-organization, as they are either contrary to Scrum values and principles (such as stakeholders walking in at the Daily Scrum or working within functional boundaries) or unnecessary for self-organization (such as the Product Owner not being at Sprint Retrospectives or the Development Team inviting external people to the Sprint Planning).

The correct answer is A, because a Sprint Retrospective should be held at the end of each Sprint. The Scrum Guide states that ''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. ... The Sprint Retrospective occurs after the Sprint Review and prior to the next Sprint Planning.''

According to the Scrum Guide1, collaboration between the Product Owner and Developers is essential for creating valuable products. The Product Owner is accountable for maximizing value resulting from work by Developers. Developers are accountable for creating a plan for the Sprint, which includes selecting items from Product Backlog that they can complete within a Sprint. The Scrum Master is accountable for establishing Scrum as defined in the Scrum Guide. They do this by helping everyone understand Scrum theory and practice, both within the Scrum Team and the organization. Therefore, two valuable actions for a Scrum Master to take if the Product Owner is not collaborating with the Development Team during the Sprint are:

Bring up the problem in the Sprint Retrospective, where the Scrum Team can inspect how they worked together and create a plan for improvements.

Coach the Product Owner in the values of Scrum and incremental delivery, and help them understand their role and responsibilities in collaborating with Developers.

The other options are not valuable actions, as they may undermine trust, respect, and self-organization within the Scrum Team.

According to the Scrum Guide1, 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 guides the Development Team in creating a ''Done'' Increment. The definition of ''Done'' is created by the development organization (or Development Team if none is available from the development organization). The definition of ''Done'' may vary significantly per Scrum Team, depending on the context. One aspect of Scrum Teams inspecting how they work toward their Product Goal is that they improve their definition of ''Done'' over time.

According to the Scrum Guide, changing the terminology of Scrum may have negative consequences, such as losing the benefits of Scrum, not understanding what has changed, or having very little change at all. Therefore, all answers apply to this question. The Scrum Guide recommends using the same terminology as in the guide to avoid confusion and misunderstanding.

Architecture and infrastructure are handled in Scrum by implementing them along with functional development of the product, and by adding them to the Product Backlog and addressing them in early Sprints, while always requiring at least some business functionality, no matter how small, as stated in [2]: ''Scrum does not distinguish between developing functionality or architecture. They are developed together, as they are both important and support each other. Architecture is not a separate phase; it is part of the product development. Architecture is added to the Product Backlog as any other feature or functionality.''

According to the Scrum Guide1, the Development Team consists of professionals who do the work of delivering a potentially releasable Increment of ''Done'' product at the end of each Sprint. Development Teams are structured and empowered by the organization to organize and manage their own work. The resulting synergy optimizes the Development Team's overall efficiency and effectiveness. Cross-functional teams have all competencies needed to accomplish the work without depending on others not part of the team. The team model in Scrum is designed to optimize flexibility, creativity, and productivity.

Three topics for the Developers to discuss at the Daily Scrum as they inspect their progress toward the Sprint Goal are:

What have we learned since yesterday, and how should we modify our plan to increase our ability to meet the Sprint Goal?

Are there any impediments blocking progress toward the Sprint Goal?

Are there any decisions that need to be made to maintain progress toward the Sprint Goal?

These topics are suggested by [6]: ''The structure of the meeting is set by the Developers and can be conducted in different ways if it focuses on progress toward the Sprint Goal. Some Development Teams will use questions, some will be more discussion based.''

According to the Scrum Guide, two things that the Scrum Team should do during the first Sprint are building at least one piece of valuable functionality and creating at least one valuable, useful Increment. These are the goals of every Sprint, regardless of its order. The other options are not things that the Scrum Team should do during the first Sprint, as they are either out of scope (such as defining major product features and a release plan architecture or making a plan for the rest of the project) or unnecessary (such as analyzing, describing, and documenting requirements for subsequent Sprints).

There are no activities that a Product Owner would typically undertake in the phase between the end of the current Sprint and the start of the next Sprint, because there is no such phase. The next Sprint starts immediately after the current Sprint, without any gaps or breaks. The other options are either activities that occur during a Sprint (such as refining the Product Backlog) or activities that are not consistent with Scrum (such as working with Quality Assurance departments or updating project plans).

According to the Scrum Guide, the Scrum Master is responsible for coaching the Scrum Team to improve its skills, tools and environment over time and adjust the Definition of Done accordingly1.The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product1.The Definition of Done should be possible to achieve given current circumstances2. Therefore, option B and E are appropriate for a Scrum Master to do, if the Scrum Team does not have the tools and environment to completely finish each selected Product Backlog item.

Option A is not appropriate because declaring the Scrum Team not ready for Scrum implies that there is a fixed set of prerequisites for using Scrum, which is not true.Scrum is a framework that can be applied to any complex product development effort1.

Option C is not appropriate because encouraging the Product Owner to accept partially done Increments until the situation improves violates the principle of transparency.Transparency requires that the Increment is a usable product that meets the current Definition of Done1.Accepting partially done Increments also increases technical debt and reduces value delivery3.

Option D is not appropriate because refocusing the current Sprint on establishing the Scrum Team's environment instead of delivering an Increment goes against the purpose of a Sprint. A Sprint is a time-boxed event that serves as a container for the other Scrum events and activities.The goal of each Sprint is to deliver a potentially releasable Increment that adheres to the current Definition of Done1.

The correct answer is B, because a product Increment does not have to be released to production at the end of each Sprint. The Scrum Guide states that ''at the end of a Sprint, the new Increment must be 'Done,' which means it must be in useable condition and meet the Scrum Team's definition of 'Done'. An increment is a body of inspectable, done work that supports empiricism at the end of the Sprint. The increment is a step toward a vision or goal.'' Therefore, a product Increment must be potentially releasable, but the decision to release it is up to the Product Owner.