Pass the Scrum Professional Scrum Master PSM-I Questions and answers with CertsForce

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. Therefore, one good way for a Scrum Team to ensure security concerns are satisfied is to add security concerns to the definition of “Done”. Another good way is to have the Scrum Team create Product Backlog items for each concern, as they are responsible for managing and refining the Product Backlog.

References: Scrum Guide

The recommended size for a Scrum Team is 10 or fewer people, as stated in the Scrum Guide: “The recommended size of a Scrum Team is small enough to remain nimble and large enough to complete significant work within a Sprint, typically 10 or fewer people.”

A Developer is accountable for creating a plan for the Sprint, the Sprint Backlog, and organizing the work required to meet the Sprint Goal, as stated in the Scrum Guide: "Developers are the people in the Scrum Team that are committed to creating any aspect of a usable Increment each Sprint. The specific skills needed by the Developers are often broad and will vary with the domain of work. However, the Developers are always accountable for:

Creating a plan for the Sprint, the Sprint Backlog;

Instilling quality by adhering to a Definition of Done;

Adapting their plan each day toward the Sprint Goal; and,

Holding each other accountable as professionals."

According to the Scrum Guide1, 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 Developers, or the Scrum Master. A Sprint would be cancelled if the Sprint Goal becomes obsolete. This might occur if the company changes direction or if market or technology conditions change. In general, a Sprint should be cancelled if it no longer makes sense given the circumstances. But, due to the short duration of Sprints, cancellation rarely makes sense.

References: Scrum Guide

According to the Scrum Guide, the timebox for a Sprint Planning event is 8 hours for a one-month Sprint, proportionally shorter for shorter Sprints. The other options are not valid, as they are either too long (such as monthly), too vague (such as whenever it’s done), or too short (such as 4 hours for a one-month Sprint).

The correct answer is D, because one of the services that a Scrum Master can provide in regard to the Daily Scrum is to teach the Development Team to keep the Daily Scrum within the 15 minute time-box. The Scrum Guide states that “the Scrum Master ensures that the Development Team has the meeting, but the Development Team is responsible for conducting the Daily Scrum. The Scrum Master teaches the Development Team to keep the Daily Scrum within the 15-minute time-box.”

The correct answers are B and D, because the length of the Sprint should be chosen based on the level of uncertainty over the technology to be used and the risk of being disconnected from the stakeholders. The Scrum Guide states that “Sprints have consistent durations throughout a development effort. A new Sprint starts immediately after the conclusion of the previous Sprint. Sprints enable predictability by ensuring inspection and adaptation of progress toward a Sprint Goal at least every calendar month. When a Sprint’s horizon is too long the Sprint Goal may become invalid, complexity may rise, and risk may increase.”

The correct answer is B, because when multiple teams work together on the same product, they should not maintain separate Product Backlogs. The Scrum Guide states that “multiple Scrum Teams often work together on the same product. One product goal unites them. Therefore, they must mutually define and comply with a definition of ‘Done’ that applies to their combined work product. … Multiple Scrum Teams working on the same product use the same Product Backlog.”

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

According to the Scrum Guide, 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 is created by the Developers and it is used to assess when work is complete on the product Increment1.

The Scrum Guide also states that the Definition of Done may vary significantly per Scrum Team, depending on the context. The Definition of Done evolves over time and becomes more stringent as the Scrum Team matures1. Therefore, it is important for the Scrum Team to regularly inspect and adapt the Definition of Done to reflect their current situation and needs.

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 Sprint1. The Sprint Retrospective focuses on three questions: What went well in the Sprint? What could be improved? What will we commit to improve in the next Sprint?1 These questions can help the Scrum Team identify potential changes to the Definition of Done that would increase the quality and value of the product.

Option A is incorrect because Product Backlog refinement is not a formal Scrum event, but rather an ongoing activity that can happen at any time during the Sprint1. Product Backlog refinement is mainly concerned with adding detail, estimates, and order to Product Backlog items1. Changing the Definition of Done during Product Backlog refinement could cause confusion and inconsistency among the Developers and the Product Owner.

Option C is incorrect because Sprint Planning is a time-boxed event that initiates a Sprint by defining a Sprint Goal and selecting Product Backlog items that deliver one coherent function1. Sprint Planning is based on the current state of the Product Backlog and the latest Definition of Done1. Changing the Definition of Done during Sprint Planning could disrupt the flow of the event and affect the scope and feasibility of the Sprint.

Option D is incorrect because prior to starting a new project is not a specific time in Scrum. Scrum does not prescribe any phases or stages for a project, but rather an empirical approach that relies on frequent inspection and adaptation of both the product and the process1. Changing the Definition of Done before starting a new project could be premature and irrelevant, as the Scrum Team may not have enough information or experience to define what ‘Done’ means for their product.

References: 1: The Scrum Guide