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

The correct answers are B and C, because these are the two primary ways a Scrum Master keeps a Development Team working at its highest level of productivity. The Scrum Guide states that “the Scrum Master serves the Development Team in several ways, including … removing impediments to the Development Team’s progress; facilitating Scrum events as requested or needed; and coaching the Development Team in self-organization and cross-functionality.” Therefore, by removing impediments and facilitating decisions, the Scrum Master helps the Development Team focus on their work and deliver value.

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

According to the Scrum Guide, multiple Scrum Teams working on the same product do not have to have the same Sprint start date. They may start their Sprints at different times, as long as they synchronize their work and integrate their Increments at least by the end of each Sprint. The other option is not valid, as it implies that having the same Sprint start date is mandatory for multiple Scrum Teams.

According to the Scrum Guide 1 , 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 reason why the Product Owner wants the Development Team to adhere to its definition of “Done” is to have complete transparency into what has been done at the end of each Sprint.

Two techniques that would be most helpful in this situation are to discuss the impediments with the Development Team, and to prioritize the list and work on them in order, as stated in [3]: “The Scrum Master should facilitate a discussion with the Development Team to identify and prioritize the impediments that are blocking their progress. The Scrum Master should then work with the Development Team and other stakeholders to remove or mitigate these impediments as soon as possible.”

According to the Scrum Guide, two actions that the Scrum Master should support in this scenario are forecasting the Product Backlog items that are most likely to meet the Sprint Goal and creating the Sprint Backlog, and discussing why this happened and what changes will make it less likely to recur during the next Sprint Retrospective. These actions are consistent with Scrum values and principles, such as empiricism, adaptation, and continuous improvement. The other options are not valid actions, as they are either wasteful (such as canceling the Sprint or continuing the Sprint Planning past its timebox) or ineffective (such as asking everyone to take more time to analyze the Product Backlog).

The Development Team must do as much work as it has told the Product Owner will be done for every Product Backlog item it selects in conformance with the definition of “Done”, as stated in the Scrum Guide 1 : “The Development Team works to forecast the functionality that will be developed during the Sprint. The Product Owner discusses the objective that the Sprint should achieve and the Product Backlog items that, if completed in the Sprint, would achieve the Sprint Goal. The entire Scrum Team collaborates on understanding the work of the Sprint.”

The correct answers are B and C, because technical debt impacts transparency in these ways. It leads to false assumptions about the current state of the system, specifically of an Increment being releasable at the end of a Sprint, as it may contain hidden defects or incomplete functionality. It also results in future work being slowed down in unpredictable ways, as development progresses and code is added, the system becomes more difficult to stabilize and maintain.

According to the Scrum Guide 1 , one aspect of Scrum Teams inspecting how they work toward their Product Goal is that they create a Sprint Goal every Sprint. The Sprint Goal is an objective set for the Sprint that can be met through the implementation of Product Backlog. It provides guidance to the Developers on why it is building the Increment. It also provides a basis for inspecting and adapting during the Sprint Review and Sprint Retrospective. The Sprint Goal is created during the Sprint Planning event.