PSM I: Applying Scrum and Coaching Better Decisions

Professional Scrum Master I, issued through Scrum.org, assesses whether a candidate understands Scrum and can apply its rules, accountabilities and values in realistic situations. The current official assessment has 80 questions in 60 minutes, with 85% required to pass; completing a course is not a prerequisite. PSM I is not a certification in organizing meetings or reporting sprint velocity to management. It tests the foundations of empiricism, self-management, purposeful events, transparent artifacts and the Scrum Master's responsibility for improving the effectiveness of the Scrum Team within its organization.

Understand why Scrum uses empiricism

Complex product work cannot always be planned in exhaustive detail at the beginning. Requirements, technical possibilities and customer needs may change as teams learn. Scrum provides a framework for making that learning frequent and visible. Its empirical approach relies on transparency, inspection and adaptation. Transparency means people can understand what is happening and what work meets the agreed quality standard. Inspection evaluates progress and risks against meaningful evidence. Adaptation changes course when the evidence shows that the current plan is unlikely to produce the intended value.

These pillars are not substitutes for accountability. A team that repeatedly misses an objective cannot simply describe every outcome as “learning” while declining to examine causes. Nor should managers treat transparency as a mechanism for blaming individuals; if reporting creates fear, information will be withheld. The Scrum values—commitment, focus, openness, respect and courage—support the behavior needed for empiricism. They encourage people to disclose uncertainty, challenge an unrealistic plan and collaborate on corrective action.

Scrum is intentionally lightweight. Teams may use engineering practices, discovery techniques and release mechanisms beyond the framework, but those additions should support rather than obscure its accountabilities and feedback loops. A detailed project schedule might be useful for a constrained dependency; it is not a replacement for an inspected Product Goal and actionable Product Backlog. Likewise, a dashboard is useful only if it helps people decide what to change, not if it becomes a scorecard detached from product value.

Distinguish the three Scrum accountabilities

The Scrum Team comprises one Product Owner, a Scrum Master and Developers. These are accountabilities within a self-managing team, not rigid job titles implying that one person writes code while another controls everyone's daily activity. The Product Owner is accountable for maximizing product value and effective Product Backlog management. Developers are accountable for creating a usable Increment each Sprint. The Scrum Master is accountable for establishing Scrum as defined in the Scrum Guide and improving the effectiveness of the team and wider organization.

A Scrum Master does not assign each Developer's daily tasks or own the Sprint Backlog on their behalf. Developers decide how to create the work needed to achieve the Sprint Goal. The Product Owner may collaborate with others on backlog refinement, but remains accountable for its effectiveness and ordering. A manager can offer valuable expertise or help remove organizational obstacles without replacing team self-management. Questions often become clearer when you ask what decision right or accountability is being assumed by the person in the scenario.

Effective Scrum Master behavior includes coaching self-management, improving collaboration, facilitating productive events when useful and helping the organization understand the benefits of empirical work. This sometimes means helping managers change habits that undermine teams: imposing work mid-Sprint without considering its consequences, equating effort with value or demanding false certainty about long-term forecasts. It may also require challenging a team that resists inspection or uses agility as an excuse to ignore quality. The Scrum Master serves the system of work rather than acting as a secretary or unilateral process enforcer.

Connect Scrum events to concrete decisions

A Sprint is a fixed-length event of one month or less that provides a regular cadence for learning and delivery. It includes Sprint Planning, Daily Scrums, Sprint Review and Sprint Retrospective. These events are not isolated rituals; each serves a specific need. Sprint Planning explains why the Sprint matters, what work might support the Sprint Goal and how selected work can be done. The Daily Scrum helps Developers inspect progress toward the Sprint Goal and adapt their plan. The Sprint Review inspects the outcome with stakeholders and adjusts future direction. The Retrospective examines how the team can improve quality and effectiveness.

Confusing the Daily Scrum with individual status reporting distorts its purpose. Developers can use it to expose dependencies, adjust plans and collaborate on obstacles; they are not required to report to a Scrum Master as their supervisor. A Sprint Review should involve feedback on the product and possible future adaptations, not just a theatrical demonstration of completed tickets. The Retrospective should lead to useful improvement actions rather than become a complaint forum whose findings never affect work.

Changes during a Sprint need judgment. The Sprint Goal provides focus while scope may be clarified and renegotiated with the Product Owner as learning occurs, without endangering the goal. A sudden emergency may alter what the team can accomplish, but routinely allowing outside stakeholders to insert unrelated requests makes planning and inspection unreliable. Only the Product Owner has authority to cancel a Sprint when the Sprint Goal becomes obsolete. PSM I questions test these boundaries because they distinguish genuine agility from unmanaged interruptions.

Make artifacts transparent through commitments

Scrum identifies three artifacts with corresponding commitments: the Product Backlog with the Product Goal, the Sprint Backlog with the Sprint Goal, and the Increment with the Definition of Done. The commitments are not decoration. The Product Goal offers a longer-term target that helps people order work. The Sprint Goal provides a coherent reason for the selected work during the current Sprint. The Definition of Done supplies the shared quality standard that determines whether work contributes to an Increment.

The Product Backlog is an emergent, ordered list of what is needed to improve the product. It is never necessarily complete, because learning changes both priorities and detail. Refinement adds clarity, appropriate sizing and useful understanding of items. The Sprint Backlog is created and adapted by Developers as they learn what work is needed. An Increment is an integrated, usable step toward the Product Goal; its completion is based on meeting the Definition of Done, not on an optimistic percentage reported in a tracker.

A common failure is moving unfinished or untested work into “done” because the Sprint is ending. That obscures transparency and transfers defects to users or later Sprints. If an item does not meet the Definition of Done, it is not part of a usable Increment. Another failure is replacing the Product Goal with a list of disconnected features. A backlog may look busy while the product fails to improve. A value-delivery approach to project work helps illustrate the broader problem of counting completed activity instead of assessing meaningful outcomes.

Coach teams through impediments without becoming a bottleneck

Impediments may include poor technical practices, unreliable environments, competing priorities, missing product decisions or organizational policies that prevent collaboration. The Scrum Master helps the team and organization address them; not every impediment can be removed personally. Coaching Developers to resolve an internal coordination problem can be more sustainable than taking over every difficult conversation. When a dependency sits outside the team's control, escalating it to an appropriate organizational owner may be necessary.

A useful intervention begins with evidence. If the team repeatedly carries over work, inspect the size and clarity of backlog items, disruptions, Definition of Done, dependencies and technical debt. Mandating overtime or reducing testing can hide the symptom while damaging future capacity. If stakeholders complain that Scrum creates uncertainty, explain what forecasts can credibly provide at different time horizons and how short cycles reduce the cost of wrong assumptions. A professional Scrum Master can support reliable decision-making without promising certainty that complex development cannot deliver.

Conflict is not automatically harmful. Product and engineering perspectives may differ legitimately about risk or sequencing. Facilitation should help people clarify facts, constraints and alternatives rather than suppress disagreement. The agile leadership beyond Scrum ceremonies concept is relevant because influence, trust and flow often matter more than faithful repetition of meeting names.

Work with the Product Owner and stakeholders effectively

The Product Owner needs clear accountability for value, but does not need to perform all discovery work alone. Collaborate with researchers, users, designers and engineers to understand needs and test assumptions. The Scrum Master can help establish productive interactions and remove organizational obstacles to accessing stakeholders. A team that receives only prewritten requirements and never learns from users is unlikely to exploit empiricism effectively. Equally, stakeholder involvement must be structured enough to avoid constant interruption and contradictory requests.

The Product Goal should guide ordering and strategic trade-offs. An urgent defect, a regulatory deadline and a new feature may all compete for capacity; discuss risk and value rather than applying a mechanical rule that always chooses one category. The Product Owner can change the Product Backlog as information develops. Developers contribute technical insight about feasibility and quality. Scrum Master coaching supports collaboration and decision clarity; it does not confer the authority to choose the product's commercial priorities.

When a Sprint Review reveals that a feature does not solve the expected customer problem, that is valuable information. The team may need to revise upcoming work and assumptions. The appropriate response is not to hide the result because the original plan was approved months earlier. Adaptation is the point of the review, provided decisions are informed by relevant people and evidence.

Prepare through scenarios that challenge assumptions

Study the current Scrum Guide and Scrum.org's Professional Scrum Competencies. Use the PSM I assessment context to practise differentiating the responsibilities of Product Owner, Scrum Master and Developers. For every practice question, state why the chosen action supports a particular accountability, pillar or commitment. Questions designed around management pressure, last-minute scope changes or incomplete work are best resolved by understanding the framework rather than memorizing a slogan.

Construct scenarios where a team fails to produce a usable Increment, a manager insists on assigning daily tasks, stakeholders refuse to attend reviews or Developers continually change the Sprint Goal. Determine what the Scrum Master can teach, facilitate or escalate, and what decision belongs to another accountability. Examine whether your answer improves transparency and self-management or simply substitutes an authority figure for the team's own reasoning.

The Professional Scrum Master career value question matters only when connected to competence in practice. Passing PSM I should mean a candidate can explain how Scrum produces feedback, why a Definition of Done protects transparency and how effective facilitation helps people improve without being directed at every step. That is a stronger foundation than memorizing the agenda of five events.