Free Scrum PSM-I Practice Exam with Questions & Answers | Set: 11

According to the Scrum Guide1, the Product Backlog is an ordered list of everything that is known to be needed in the product. It is the single source of requirements for any changes to be made to the product. The Product Owner is accountable for maximizing value resulting from work by Developers. The Product Owner is also accountable for effective Product Backlog management, which includes:

Developing and explicitly communicating the Product Goal;

Creating and clearly communicating Product Backlog items;

Ordering Product Backlog items; and

Ensuring that the Product Backlog is transparent, visible and understood.

Therefore, the Product Owner is responsible for clearly expressing Product Backlog items.

References: Scrum Guide

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, if a Product Backlog item worked on during the Sprint does not meet the definition of “Done”, two things that should happen with the undone Product Backlog item are:

Put it on the Product Backlog for the Product Owner to decide what to do with it, as they are accountable for effective Product Backlog management and ordering.

Do not include the item in the Increment this Sprint, as it does not meet the quality standards and may compromise value.

The other options are not appropriate, as they may compromise transparency, inspection, or adaptation.

References: Scrum Guide

According to the Scrum Guide, the action that the Scrum Master should take when the Team decides that a Sprint Retrospective is unnecessary is to begin facilitating productive and useful Sprint Retrospectives. The Sprint Retrospective is an essential event for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint. The Scrum Master is responsible for ensuring that this event takes place and that positive outcomes are achieved. The other options are not valid actions, as they either imply that the Scrum Master complies with or ignores the decision of the Team (such as complying with it, calling a meeting with senior management, or consulting with the Product Owner), which is not consistent with Scrum values and principles.

The correct answers are B and D, because these are the most appropriate responses for the Scrum Master. The Scrum Master should coach the team on why the Daily Scrum is important as an opportunity to update the plan, inspect the progress, and synchronize the activities of the Development Team. The Scrum Master should also learn why the Development Team wants this and work with them to improve the outcome of the Daily Scrum, rather than imposing a decision or accepting their request without question.

The correct answers are B, E, and F, because these activities would probably help the team in starting up. Having the Scrum Team members introduce themselves and give a brief background of their skills and work history helps build trust and rapport among them. Ensuring the team understands they need a definition of “Done” helps create transparency and alignment on the quality standards for the product. Asking the Product Owner to discuss the product or project, its history, goals, and context, as well as answer questions helps clarify the vision and value of the product.

References: [Suggested Reading for Professional Scrum Master™ I]

The correct answer is C, because a Development Team should deliver an increment of working software that is “done” by the end of a Sprint. The Scrum Guide states that “the Increment is the sum of all the Product Backlog items completed during a Sprint and the value of the increments of all previous Sprints. 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’.”

When many Development Teams are working on a single product, the definition of “Done” must be shared by all Development Teams and make their combined work potentially releasable, as stated in [4]: “When multiple teams work together on one product they must mutually define and comply with the same Definition of Done. This makes sure all Increments adhere to a consistent quality level.”

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 topics that are appropriate for discussion are those that relate to how the team does its work, such as processes, tools, communication, collaboration, quality, etc. The value of work currently represented in the Product Backlog and arranging the Sprint Backlog for the next Sprint are not appropriate topics for discussion in a Sprint Retrospective, as they belong to the Sprint Review and Sprint Planning events respectively.

According to the Scrum Guide1, when multiple Scrum Teams are working together on one product, they must coordinate their work with each other. One way to do this is through Nexus, a framework for scaling Scrum. Nexus helps to reduce cross-team dependencies and integration issues by making them more transparent. Multiple Scrum Teams working on one product use one Product Backlog.

References: Scrum Guide, Nexus Guide