Professional Scrum Master I: Applying Scrum Under Real Constraints

The Professional Scrum Master I (PSM I) assessment asks whether a candidate understands Scrum and can apply it when a team faces real pressures. It is not a qualification in running meetings quickly or assigning work efficiently. A Scrum Master helps establish Scrum as defined in the Scrum Guide and helps the Scrum Team and organization understand how empiricism, accountability, self-management, and continuous improvement produce value. That responsibility becomes visible when a manager demands a fixed scope despite new evidence, a team treats the Daily Scrum as a status report, or a Product Owner cannot make decisions because stakeholders keep bypassing a coherent Product Backlog.

Scrum.org's PSM I certification is based on the Scrum framework and professional competencies. As of October 2026, the official Scrum Guide still identifies its November 2020 edition as current. Scrum.org lists the PSM I assessment as 80 questions in 60 minutes, with a passing score of 85%. These details should be verified before booking, but understanding them is less important than reasoning accurately about why Scrum's accountabilities, events, artifacts, and commitments exist. The assessment is a demonstration of knowledge; attending a class is not mandatory, and Scrum.org describes its professional certification as a lifetime credential.

Start with empiricism rather than a calendar of ceremonies

Scrum uses an empirical approach because complex work cannot be completely predicted in advance. The team makes important information visible, inspects progress and outcomes at useful intervals, and adapts plans based on what it learns. Transparency, inspection, and adaptation are not separate slogans. Inspection without transparency yields false confidence, while inspection without the willingness to adapt merely documents a problem that continues unchanged.

Consider a team building a new account-onboarding process. Initial research suggests that account verification is the largest source of friction. After two weeks, testing reveals that users actually abandon the process because the consent explanation is confusing. An empirical response is to reassess the Product Backlog and the next useful Increment based on evidence. It is not to continue the original plan solely because that plan was approved before the discovery.

The Scrum Master helps the team and its stakeholders understand the implications of that uncertainty. They should not promise that fixed scope, fixed time, fixed staffing, and zero change will produce the best outcome in a complex product environment. A Sprint has a fixed duration, but what the team learns may influence work selection and future planning. Empiricism does not mean an absence of accountability: each Sprint should create an inspectable result and meaningful information about progress toward a Product Goal.

Scrum's five values—commitment, focus, openness, respect, and courage—support this way of working. If a Developer conceals a critical defect to protect a reporting metric, transparency suffers. If a manager interrupts the team daily with unrelated commitments, focus suffers. Values are most useful when they explain a decision under pressure rather than appear as memorized words on a slide.

Understand the three accountabilities and their boundaries

The Scrum Team contains one Product Owner, one Scrum Master, and Developers. These are accountabilities, not a hierarchy with the Scrum Master supervising the other roles. The Product Owner is accountable for maximizing the value of the product resulting from the team's work, including effective Product Backlog management. Developers are accountable for creating any aspect of a usable Increment each Sprint. The Scrum Master is accountable for establishing Scrum and for the Scrum Team's effectiveness.

Distinguish accountability from doing every task personally. The Product Owner may delegate Product Backlog refinement activity, but remains accountable for the Product Backlog. Developers can decide how to organize their technical work rather than awaiting the Scrum Master's task assignments. A Scrum Master may teach facilitation or help address an organizational impediment, but should not become the default approver of every design choice.

Real organizations complicate these boundaries. A senior executive may hold budget authority, a line manager may supervise employment matters, and a project manager may coordinate work outside the Scrum Team. Those arrangements do not automatically violate Scrum, but they do not override its accountabilities inside the framework. The Product Owner needs sufficient authority to order the Product Backlog and make meaningful value choices. Developers need room to decide how to create the Sprint's work. The Scrum Master should surface when an external policy undermines those conditions.

The related Professional Scrum Product Owner I certification emphasizes the Product Owner's value and decision-making responsibilities. Its overlap with PSM I is deliberate: the Scrum Master needs to understand how Product Ownership works without taking the Product Owner's accountability away. Someone who mistakes cooperation for interchangeable roles will struggle with scenario questions and with real team boundaries.

Connect Scrum events to their purpose

The Sprint is the container for the other Scrum events. It is a fixed-length period of one month or less in which the team creates a usable, valuable Increment. A new Sprint begins immediately after the previous one ends. Events establish a regular cadence for transparency, inspection, and adaptation; they are not simply meetings to be completed as a matter of compliance.

Sprint Planning addresses why the Sprint is valuable, what can be Done during it, and how the selected work will be achieved. The Product Owner proposes how the product could increase value, while the Scrum Team collaborates on a Sprint Goal. Developers select Product Backlog items through discussion and create a workable plan. The Sprint Goal is a commitment associated with the Sprint Backlog, not an afterthought pasted onto a predetermined task list.

The Daily Scrum is a 15-minute event for Developers to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary. It is not inherently a round-robin report to the Scrum Master or a forum in which an external manager assigns each person a new task. Developers can choose an appropriate structure so long as the event meets its purpose. Other communication and coordination can happen throughout the day; Scrum does not confine collaboration to one timebox.

Sprint Review brings the Scrum Team and key stakeholders together to inspect the outcome of the Sprint and consider future adaptations. It is a working session about the product and the environment, not merely a theatrical demonstration or a sign-off ceremony. The Sprint Retrospective examines how the team can increase quality and effectiveness, including people, interactions, tools, processes, and the Definition of Done. A retrospective that repeats the same complaint without changing behavior is not fulfilling its practical purpose.

Relate artifacts to commitments and evidence

Scrum defines three artifacts with corresponding commitments. The Product Backlog commits to a Product Goal. The Sprint Backlog commits to the Sprint Goal. The Increment commits to the Definition of Done. These relationships are important because they make the artifacts more than lists or deliverable inventories. Each commitment explains what reliable information the artifact is meant to provide.

A Product Goal describes a future state that the Scrum Team can plan against. The Product Backlog is an ordered, emergent list of what is needed to improve the product; it is not an immutable specification of every requirement. Ordering may reflect expected value, dependencies, risk, opportunity, and what the team has learned. The Product Owner is accountable for effective management of that list, while the team may help with clarification, decomposition, and sizing.

The Sprint Backlog includes the Sprint Goal, selected Product Backlog items, and the plan for delivering them. Developers adapt the plan as they learn, and scope may be clarified or renegotiated with the Product Owner as appropriate without compromising the Sprint Goal. A team that treats every originally selected task as untouchable may optimize adherence to a plan instead of achieving a valuable outcome.

An Increment is usable, meets the Definition of Done, and is additive to previous Increments. Work that has not met the Definition of Done is not part of the Increment merely because its code is mostly written or a stakeholder wants credit for it. Several Increments can be created during a Sprint, and delivery of value need not wait for the Sprint Review. The relationship among Product Backlogs, Sprint Backlogs, and Increments matters because confusion between an artifact and its commitment produces recurring errors in planning and reporting.

Support self-management and remove impediments without taking over

A Scrum Master serves the Developers, the Product Owner, and the organization in different ways. For the Developers, this can mean coaching self-management and cross-functionality, helping them focus on creating high-value Increments, and encouraging timely removal of impediments. For the Product Owner, it can mean helping establish empirical product planning and effective Product Goal and Product Backlog practices. At the organizational level, the Scrum Master can lead, train, and coach the adoption of Scrum and help stakeholders understand the effects of their interactions with teams.

An impediment is not simply any task the team does not enjoy. It is something that materially obstructs its ability to achieve its goals. A system that requires four approval layers for every deployment may be an organizational impediment. A Developer discovering a challenging design question is normal work and should not automatically be escalated out of the team's hands. The Scrum Master should help make constraints visible and assist with resolution at an appropriate level, not turn into a personal problem-solving service that removes accountability from Developers.

Facilitation matters because a group can hold many meetings without developing shared understanding. The facilitator can make the purpose clear, help quieter participants contribute, expose assumptions, and guide a decision process without secretly deciding the outcome. Coaching asks questions that help people discover better approaches. Mentoring draws on experience to offer guidance. Teaching explains Scrum concepts. Skilled Scrum Masters select among these interventions as context demands rather than repeating one technique in every situation. Strong facilitation for Scrum Masters means enabling constructive participation and decisions while leaving accountability with the people who own the outcome.

When a team repeatedly misses its Sprint Goal, the Scrum Master should seek evidence. Was the Goal poorly formed? Did unexpected production support consume capacity? Did the team over-select work? Were hidden dependencies discovered late? A response based on inspection might involve reducing work in progress, improving refinement, involving outside specialists, or addressing organizational interruption. Simply increasing pressure or assigning blame undermines the openness needed to find the real cause.

Handle familiar anti-patterns with framework reasoning

Many PSM I situations are difficult because a flawed approach looks superficially efficient. Imagine a stakeholder asking the Scrum Master to add urgent scope to a Sprint without involving the Product Owner. The answer is not to defend a rigid plan at any cost, nor to accept all requests immediately. The Product Owner is accountable for value decisions, Developers own the Sprint plan, and the Sprint Goal provides a coherent basis for negotiation. The Scrum Master supports constructive collaboration within those constraints.

Another pattern occurs when the organization measures each Developer's output rather than the team's valuable Increment. Individual utilization can encourage optimizing local activity at the expense of integration, testing, and shared ownership. The Scrum Master can help stakeholders understand why a cross-functional Scrum Team should be evaluated with regard to delivered value, quality, and the ability to adapt, not solely task completion volume.

Or consider a Product Owner who cannot be reached during a Sprint. Developers can continue technical work, but unresolved product choices threaten value and clarity. The Scrum Master should help the organization improve Product Owner availability and decision authority rather than quietly becoming a substitute Product Owner. Similarly, if an Increment is not Done, the team should make that fact transparent rather than lowering the Definition of Done for a one-time report.

The point of scenario practice is to identify the purpose of the disrupted event or accountability, explain what information is missing, and select an intervention that strengthens empiricism and ownership. A memorized list of “best practices” can be misleading when it conflicts with the actual problem.

Prepare by testing decisions, not merely terminology

The official Scrum Guide is short enough to read several times, but a candidate should be able to reconstruct the relationships among its concepts without looking at the text. Start with a Product Goal, derive a plausible Sprint Goal, identify what belongs in each artifact, and then explain what happens if an unexpected event changes the value of the remaining Product Backlog. Practice differentiating what Scrum requires from practices that teams may choose, such as particular task boards, estimation techniques, or the format of a Daily Scrum.

Use Scrum.org's official PSM I information and open assessments to assess understanding. After each difficult question, explain why the alternatives fail rather than remembering only which option was correct. Questions about timeboxes, participation, authority, and unfinished work benefit from careful reading of the most current official Scrum Guide. Do not import rules from other agile frameworks simply because the terminology seems familiar.

Scrum certifications assess distinct accountabilities and levels of application, but PSM I is fundamentally about creating the conditions in which a Scrum Team can inspect reality, adapt responsibly, and produce a usable Increment. A strong Scrum Master does not protect process theater. They help people use Scrum's structure to notice the truth sooner and make better product decisions from it.