Free Practice Questions for Scrum PSM-I Exam

According to the Scrum Guide 1 , each event in Scrum is a formal opportunity to inspect and adapt something. These events are specifically designed to enable critical transparency and inspection. Failure to include any of these events results in reduced transparency and is a lost opportunity to inspect and adapt. All events are time-boxed events, such that every event has a maximum duration. Once a Sprint begins, its duration is fixed and cannot be shortened or lengthened. The remaining events may end whenever the purpose of the event is achieved, ensuring an appropriate amount of time is spent without allowing waste in the process. The time-box for the Daily Scrum is 15 minutes or less for a one-month Sprint. Its location and time remain constant.

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 1 , only people who are actively working on items in the Sprint Backlog participate in updating it during a Sprint; this includes tracking progress made on those items. This is typically done by Developers updating their remaining work every day after their Daily Scrum. The Development Team tracks this total work remaining at least for every Daily Scrum to project the likelihood of achieving their Sprint Goal. The Developers are self-organizing and decide how to turn Product Backlog items into an Increment of value. Therefore, the Scrum Master should allow the Development Team to self-manage and determine for itself what to do regarding the logistical challenges of meeting in different locations.

The Product Owner is responsible for engaging the stakeholders, as stated in the Scrum Guide 1 : “The Product Owner is one person, not a committee. The Product Owner may represent the desires of a committee in the Product Backlog, but those wanting to change a Product Backlog item’s priority must address the Product Owner.”

According to the Scrum Guide 1 , the Sprint Backlog is the property of the Developers and no one else can tell them which items they should work on. The Developers can select any item from the Product Backlog that they forecast they can complete within a Sprint. The Developers are self-organizing and decide how to turn Product Backlog items into an Increment of value. Therefore, no one owns a Sprint Backlog item, but the entire Development Team is accountable for it.

According to the Scrum Guide, the best approach for Scrum Teams in order to produce valuable Increments is to have each Developer work on the component where they feel that they can contribute. This means that the Developers can self-organize and collaborate effectively to deliver a valuable Increment that meets the Definition of Done and the Sprint Goal. The other options are not valid approaches, as they either imply that the Developers work in silos or rely on external people (such as developing functionality from beginning to end, working on an independent set of components, or working only as an independent layer of the system).

According to the Scrum Guide, every Scrum Team should have the competencies and skills needed to deliver an Increment in a Sprint. This means that the Developers can work on any aspect of the product without depending on others outside the team. The other options are not valid descriptions of what every Scrum Team should have, as they either imply that the Developers work in silos or rely on external people (such as a lead developer or representatives from different departments).

According to the Scrum Guide, the Development Team is responsible for creating a “Done” Increment that meets the Definition of “Done”. User documentation is part of the Definition of “Done” in this scenario, so the Development Team must create it. The other options are not consistent with Scrum values and principles, such as self-organization, cross-functionality, and empiricism.

The best answer is C. When multiple Scrum Teams are working together on a product, they must mutually define and comply with the same Definition of Done. This is because the Definition of Done creates transparency and ensures that the product Increment meets the quality standards required for the product 1 . If each Scrum Team has its own Definition of Done, it may lead to inconsistencies, conflicts, and technical debt in the product. Therefore, the Scrum Teams should collaborate and agree on a common Definition of Done that applies to all Product Backlog Items and Increments. This way, the Scrum Teams can deliver a potentially releasable product Increment at the end of every Sprint 2 .

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