PSM-I Scrum Professional Scrum Master I Free Practice Exam Questions (2025 Updated)

According to the Scrum Guide, 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 team relations, Definition of Done, and processes, tools, communication, collaboration, quality, etc. The other options are not appropriate topics for discussion in a Sprint Retrospective, as they belong to other Scrum events (such as arranging the Sprint Backlog for the next Sprint in the Sprint Planning or evaluating the value of work in the Product Backlog in the Sprint Review).

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

References: Scrum Guide

According to the Scrum Guide1, the Daily Scrum is an event for the Developers of the Scrum Team. The purpose of the Daily Scrum is to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary, adjusting the upcoming planned work. The Scrum Master and Product Owner may attend as observers, but only if it is useful for the Developers.

References: Scrum Guide

According to the Scrum Guide1, 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. The Scrum Master serves the Developers in several ways, including:

Coaching them in self-management and cross-functionality;

Helping them to create high-value products;

Removing impediments to their progress;

Facilitating Scrum events as requested or needed; and,

Coaching them in organizational environments in which Scrum is not yet fully adopted and understood.

The Scrum Master serves the Product Owner in several ways, including:

Helping find techniques for effective Product Goal definition and Product Backlog management;

Helping the Scrum Team understand the need for clear and concise Product Backlog items;

Helping establish empirical product planning for a complex environment; and,

Facilitating stakeholder collaboration as requested or needed.

The Scrum Master serves the organization in several ways, including:

Leading, training, and coaching the organization in its Scrum adoption;

Planning and advising Scrum implementations within the organization;

Helping employees and stakeholders understand and enact an empirical approach for complex work; and,

Removing barriers between stakeholders and Scrum Teams.

Therefore, two things that are true about the Scrum Master role are:

The Scrum Master teaches the Development Team to keep the Scrum meetings to their time-box, as they help everyone understand Scrum theory and practice.

The Scrum Master helps those outside the team interact with the Scrum Team, as they serve both the Product Owner and the organization.

The other options are not true about the Scrum Master role, as they imply that they have authority or responsibility over things that are not within their accountability.

References: Scrum Guide

The correct answer is B, because there is no role called “Project Manager” in Scrum. The Scrum Guide states that “Scrum recognizes no titles for Development Team members other than Developer, regardless of the work being performed by the person; there are no exceptions to this rule.” Therefore, Scrum has only three roles: Product Owner, Scrum Master, and Developer.

According to the Scrum Guide, the Product Owner is accountable for clearly expressing Product Backlog items, as he or she is responsible for managing and prioritizing the Product Backlog. The other options are not valid, as they imply that the Product Owner can be replaced by a business analyst, or that the Scrum Master or the Developers can express the Product Backlog items.

The correct answer is B, because the Product Owner does not make sure the team selects enough from the Product Backlog for a Sprint to satisfy the stakeholders. The Scrum Guide states that “the number of items selected from the Product Backlog for the Sprint is solely up to the Development Team. Only the Development Team can assess what it can accomplish over the upcoming Sprint.” Therefore, the Development Team is responsible for choosing the scope of work for a Sprint.

The correct answers are A, C, and E, because these are feedback loops in Scrum. The Sprint Review is a feedback loop that allows the Scrum Team and the stakeholders to inspect the Increment and adapt the Product Backlog. The Sprint Retrospective is a feedback loop that allows the Scrum Team to inspect itself and create a plan for improvements. The Daily Scrum is a feedback loop that allows the Development Team to inspect its progress and plan its work for the next 24 hours.

According to the Scrum Guide1, there are three roles in a Scrum Team:

The Product Owner

The Developers

The Scrum Master

The Product Owner is accountable for maximizing value resulting from work by Developers. Developers are accountable for creating a plan for the Sprint, the Sprint Backlog. 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. Every Scrum team must have a Product Owner and Scrum Master, as outcomes are affected by their participation and availability. The other options are false, as they imply that the Product Owner and Scrum Master roles are optional or interchangeable.

References: Scrum Guide

According to the Scrum Guide1, 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 a result of Sprint Planning, as is the Sprint Backlog.

References: Scrum Guide

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, management external to the Scrum Team is not involved in the Daily Scrum at all. The Daily Scrum is an internal event for the Development Team to inspect their progress toward the Sprint Goal and plan their work for the next 24 hours. The other options are not valid ways for management to be involved in the Daily Scrum, as they are either intrusive (such as giving an update or speaking on behalf of others) or unnecessary (such as being represented by the Product Owner or the Scrum Master).

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 A, because the Product Owner does not determine how many Product Backlog items the Development Team selects for a Sprint. The Scrum Guide states that “the number of items selected from the Product Backlog for the Sprint is solely up to the Development Team. Only the Development Team can assess what it can accomplish over the upcoming Sprint.” Therefore, the Development Team is responsible for choosing the scope of work for a Sprint.

According to the Scrum Guide, when many Scrum Teams are working on a single product, they must have a Definition of Done that makes their combined work potentially releasable. This ensures that there is a clear and consistent understanding of what “Done” means for the product and that there is no technical debt or unfinished work at the end of each Sprint. The other options are not valid descriptions of the Definition of Done for multiple Scrum Teams, as they either create inconsistency, confusion, or waste (such as having different definitions, discussing and reconciling differences during a hardening Sprint, or having the Scrum Masters define a common Definition of Done).

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.

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 Scrum Guide also states that “when multiple Scrum Teams are working together on a product, they must mutually define and comply with the same Definition of Done. This ensures transparency and consistency among the teams and makes their combined work potentially releasable.”

A, B, and D are not correct answers.

A. Each Scrum Team uses its own, but must make their definition clear to all other teams so the differences are known.

This answer does not reflect the Scrum value of alignment2. Having different Definitions of Done for each Scrum Team can create confusion and inconsistency in the quality and completeness of the product. It can also make it difficult to integrate and deliver a coherent and valuable Increment at the end of each Sprint.

B. The Scrum Masters from each Scrum Team define a common Definition of Done.

This answer does not reflect the Scrum principle of self-organization3. The Definition of Done should be created by the Developers who are responsible for delivering the Increment, not by the Scrum Masters who are responsible for facilitating and coaching the Scrum Teams. The Scrum Masters can help the Developers understand and apply the Definition of Done, but they should not impose it on them.

D. Each Scrum Team defines and uses its own. The differences are discussed and reconciled during a hardening Sprint.

This answer does not reflect the Scrum value of focus2. Having different Definitions of Done for each Scrum Team can lead to technical debt or rework that requires a hardening Sprint to resolve. A hardening Sprint is an anti-pattern that violates the rule of delivering a potentially releasable Increment at the end of each Sprint4.

The correct answers are B and E, because these statements are true about the length of the Sprint. It is best to have Sprints of consistent length throughout a development effort, as this helps establish a reliable rhythm and cadence for the Scrum Team and the stakeholders. All Sprints must be one month or less, as this ensures that the Scrum Team can inspect and adapt frequently and deliver value incrementally.

According to the Scrum Guide, the Scrum Team is responsible for removing a Developer from the Scrum Team if necessary, as they are self-managing and accountable for creating valuable Increments. The other options are not valid, as they imply that someone else outside the Scrum Team has the authority to remove a Developer (such as the Scrum Master, the Product Owner, or the hiring manager), which is not consistent with Scrum values and principles.

According to the Scrum Guide, estimates are made by the people doing the work, which is the Development Team. The Development Team is responsible for all estimates in the Product Backlog and the Sprint Backlog. The other options are not valid guidelines for estimating work in Scrum, as they are either too prescriptive (such as requiring story points or relative units), incorrect (such as forbidding estimating or having the Product Owner make estimates), or unnecessary (such as checking estimates with the Development Team).