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

The Scrum Master is accountable for establishing Scrum as defined in the Scrum Guide and for helping everyone understand Scrum theory and practice. Option A is correct because Scrum events are timeboxed, and the Scrum Master helps the Scrum Team understand and properly use those timeboxes so events remain focused, productive, and effective. Teaching the team how timeboxing supports empiricism, focus, and predictability is part of the Scrum Master’s service to the team.

Option D is also correct because the Scrum Master serves the organization by helping those outside the Scrum Team understand how to interact effectively with the team. This includes removing barriers between stakeholders and Scrum Teams and coaching the organization in Scrum adoption.

Option B is incorrect because Scrum does not require the Scrum Master to maintain burndown charts. Option C is incorrect because Developers are self-managing and the Scrum Master does not assign tasks. Option E is incorrect because the Sprint Review is a collaborative inspection of the Increment, and completion is determined by whether work meets the Definition of Done, not by the Scrum Master declaring it.

The correct answers are A and B. When multiple Scrum Teams work on the same product, Scrum calls for one Product Owner and one Product Backlog for that product. This ensures a single source of prioritization, clear accountability for maximizing value, and consistent product direction. One Product Owner helps avoid conflicting priorities across teams and provides one clear voice for product decisions.

One Product Backlog is equally important because it creates transparency for all work needed to develop the product. If each team had its own separate Product Backlog, the organization would risk fragmentation, duplicate work, inconsistent ordering, and confusion about the overall product direction. A single Product Backlog supports coordinated planning and alignment across all teams contributing to the same product.

Options C, D, and E are incorrect because they divide product accountability across multiple backlogs or multiple Product Owners. Scrum does not define a Chief Product Owner structure. For one product, there should be one Product Owner and one Product Backlog, even when multiple Scrum Teams are involved. This setup best supports focus, transparency, and value optimization.

According to the Scrum Guide, the Sprint Backlog may include any items that are a decomposition of the selected Product Backlog items, such as user stories, tasks, use cases, tests, or others. The Sprint Backlog is the Developers’ plan for the Sprint, and it contains all the work that they forecast they can do to achieve the Sprint Goal and create a “Done” Increment. The other options are not valid, as they are either too specific (such as user stories or tasks) or too vague (such as tests).

The correct answer is D because Scrum Teams are self-managing. That means the Scrum Team, and especially the Developers with respect to Sprint Backlog execution, manages its own work rather than relying on a project manager, Product Owner, or Scrum Master to make sure individuals complete assigned tasks. Scrum does not operate through command-and-control task enforcement. Instead, the team collaborates to achieve the Sprint Goal and holds itself collectively accountable.

Option A is incorrect because Scrum does not define a Project Manager role responsible for directing daily task completion. Option B is incorrect because the Product Owner is accountable for maximizing value, not managing the team’s day-to-day task execution. Option C is incorrect because the Scrum Master coaches and facilitates Scrum but does not supervise or police whether each person does their tasks. Option E is incorrect because the roles listed do not all share this responsibility.

A key Scrum principle is collective accountability. The Scrum Team organizes its own work, inspects progress, and adapts as needed. Rather than focusing on whether each individual completes personal assignments, Scrum emphasizes whether the team is progressing toward the Sprint Goal and delivering a Done Increment.

According to the Scrum Guide 1 , there is no such thing as a Release Sprint in Scrum. A Release Sprint implies that there are other Sprints that don’t produce a potentially releasable Increment, which violates the core principle of Scrum. Every Sprint should result in a “Done”, useable, and potentially releasable product Increment.

According to the Scrum Guide 1 , 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 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.

The correct answer is B, because the time-box for a Daily Scrum is 15 minutes. The Scrum Guide states that “the Daily Scrum is a 15-minute time-boxed event for the Development Team to synchronize activities and create a plan for the next 24 hours.”

According to the Scrum Guide 1 , the Developers are self-organizing and decide how to turn Product Backlog items into an Increment of value. No one tells them how to do their work. The Developers are accountable for creating a plan for the Sprint, the Sprint Backlog. The other roles are not responsible for making sure everyone on the Development Team does their tasks for the Sprint.

The best answer is B. The need for the team to learn based on doing work and measuring results.

The Sprint length should be chosen based on the complexity and volatility of the product and the environment, as well as the team’s capability and Definition of Done. The Sprint length should enable the team to deliver a usable Increment of value that meets the feedback needs of the stakeholders and the business. The Sprint length should also allow the team to inspect and adapt their work processes and practices based on the outcomes of the Sprint.

The other options are not valid reasons for choosing the Sprint length. The organization’s mandate, team formation, and release schedule should not dictate the Sprint length, but rather be aligned with it. The Scrum Team should have the autonomy to choose the Sprint length that best suits their product and context.

You can learn more about how to choose the right Sprint length from these sources: How Long A Sprint Should Be? , How to Choose the Right Sprint Length in Scrum , What is a Sprint? , Determining the Sprint Length , and Sprint Length: What’s the Right Length? .