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

The correct answer is B because cross-functional teams in Scrum are not optimized to work on only one component or one technical layer of a system. A cross-functional Scrum Team has all the skills necessary to create value each Sprint and deliver a usable Increment. This means the team should be capable of working across the different skills and disciplines needed to complete Product Backlog items according to the Definition of Done.

If a team is organized around only one component or specialty, it creates handoffs, dependencies, and silos. Those conditions reduce agility and make it harder to deliver a complete Increment each Sprint. Scrum instead favors teams that can collaborate across analysis, design, development, testing, and other needed capabilities so they can produce finished product value rather than partial technical output.

Cross-functionality supports self-management and reduces delays caused by waiting on other specialists or teams. It helps the Scrum Team focus on outcomes instead of isolated activities. In Scrum, the goal is not local optimization of a single layer or function. The goal is delivering complete, useful, high-value Increments frequently and transparently.

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

The correct answer is A, because if two Scrum Teams are added to the development of a product that previously had only one Scrum Team, the immediate impact on the productivity of the original Scrum Team is likely to decrease. This is because adding more teams may introduce some challenges and trade-offs, such as increased communication and coordination overhead, reduced alignment and cohesion, and potential conflicts or dependencies.

According to the Scrum Guide, when multiple Scrum Teams are working on the same product, they should integrate their Increments every Sprint, in order to accurately inspect what is done and ensure that there is no technical debt or unfinished work at the end of each Sprint. The other options are not valid, as they imply that integration can be skipped, delayed, or done only for some teams, which is not consistent with Scrum values and principles.

According to the Scrum Guide 1 , the purpose of the Sprint Retrospective is to plan ways to increase quality and effectiveness. The Scrum Team inspects how the last Sprint went with regards to individuals, interactions, processes, tools, and their Definition of Done. Inspected elements often vary with domain, practices, and people involved. The Scrum Team identifies the most helpful changes to improve its effectiveness. The most impactful improvements are addressed as soon as possible. They may even be added to the Sprint Backlog for the next Sprint. Therefore, two appropriate topics for discussion during a Sprint Retrospective are:

Identifying high priority process improvements for the next Sprint.

How the team collaborates.

The other options are not relevant or appropriate for the Sprint Retrospective.

A Developer becomes accountable for an item in the Sprint Backlog never as Developers on the Scrum Team share accountability for items in the Sprint Backlog, as stated in the Scrum Guide: “The Developers can select whatever items they want as long as they feel they can complete the work by the end of the Sprint. The Scrum Team is responsible for all estimates. The Product Owner may influence the Developers by helping them understand and select trade-offs, but the people who will perform the work make the final estimate.”

 According to the Scrum Guide 1 , when multiple Scrum Teams are working together on the same product, they must mutually define and comply with the same definition of “Done”, which includes creating an integrated Increment at least by the end of each Sprint. The Scrum Master should teach and coach the Developers that it is their responsibility to work with other Scrum Teams to create an integrated Increment that meets the definition of “Done”. The other options are not aligned with Scrum values and principles.

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.

The Product Owner is responsible for ensuring that the most valuable functionality is produced first, at all times, by ordering and prioritizing the Product Backlog. The Product Owner also interacts with stakeholders to understand their needs and expectations, and to communicate the vision and progress of the product. The other options are not part of the Product Owner role according to Scrum, as they are either too prescriptive or too technical.

According to the Scrum Guide 1 , 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 Sprint Retrospective occurs after the Sprint Review and prior to the next Sprint Planning. The purpose of the Sprint Retrospective is to plan ways to increase quality and effectiveness. The Product Owner is part of the Scrum Team and should participate as a Scrum Team member in the Sprint Retrospective.

The correct answers are B and D, because the length of the Sprint should be chosen based on the level of uncertainty over the technology to be used and the risk of being disconnected from the stakeholders. The Scrum Guide states that “Sprints have consistent durations throughout a development effort. A new Sprint starts immediately after the conclusion of the previous Sprint. Sprints enable predictability by ensuring inspection and adaptation of progress toward a Sprint Goal at least every calendar month. When a Sprint’s horizon is too long the Sprint Goal may become invalid, complexity may rise, and risk may increase.”

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 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, when the Scrum Team gets caught in an internal disagreement about which development techniques to apply, two techniques that the Scrum Master could use are:

Involve the complete Development Team, as they are responsible for managing and refining their own work.

Use coaching techniques, such as open questions and active listening, to help the Development Team resolve their conflict and reach a consensus.

The other options are not appropriate, as they may undermine the self-organization and empowerment of the Developers.

The best two answers are B and D. These two ways of dealing with regulatory compliance issues are consistent with Scrum’s values and principles, as they allow the Scrum Team to deliver valuable and potentially releasable increments of the product while meeting the necessary standards and regulations. They also enable the Scrum Team to inspect and adapt their compliance strategy based on feedback and changing requirements.

A is not a good answer because it creates a separate silo of responsibility for compliance issues, which can lead to delays, conflicts, and inefficiencies. It also violates the Scrum value of transparency, as the compliance team may not have full visibility into the product development process.

C is not a good answer because it implies a waterfall approach that assumes all the compliance requirements are known and fixed upfront, which is rarely the case. It also reduces the flexibility and responsiveness of the Scrum Team, as they may have to follow a rigid plan that does not reflect the current reality of the product or the market.

According to the Scrum Guide, the Scrum Team consists of three roles: the Scrum Master, who coaches and facilitates the team; the Product Owner, who manages and prioritizes the Product Backlog; and the Development Team, who delivers a potentially releasable Increment at the end of each Sprint. Users and customers are not roles on the Scrum Team, but they are stakeholders who may provide feedback and input to the product.

According to the Scrum Guide 1 , 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 Daily Scrum optimizes the probability that the Developers will meet the Sprint Goal. Every day, the Developers should understand how they intend to work together as a self-organizing team to accomplish the Sprint Goal and create the anticipated Increment by the end of the Sprint. If the frequency of the Daily Scrum were to be lowered to every two or three days, some key concerns would be:

Opportunities to inspect and adapt the Sprint Backlog are lost, which may result in wasted work or missed dependencies.

Impediments are raised and resolved more slowly, which may hinder the progress and quality of the work.

The Sprint plan may become inaccurate, as changes in requirements, risks, or priorities are not reflected in a timely manner.

The other options are not valid concerns, as they are not aligned with Scrum values and principles.

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