Scrum.org PSM I: Making Empiricism Work in Scrum

A team can hold every Scrum event and still learn almost nothing from the work it performs. The Sprint Planning meeting becomes a list of tasks, the Daily Scrum becomes a status report for a manager, and the Sprint Review becomes a slide presentation where stakeholders cannot influence the product. The PSM I assessment from Scrum.org tests understanding of the Scrum framework and the responsibilities needed to make empiricism work. The credential is not a qualification in chairing meetings. It is evidence that a practitioner understands accountabilities, Scrum values, artifacts, commitments, events and the conditions required for a self-managing team to deliver useful increments.

Scrum works by making decisions frequently from observable results rather than pretending that uncertainty can be eliminated at the start. The Scrum Master helps the team and wider organization use that feedback productively. They do not serve as a substitute project manager who distributes every task or decides what customers need. Preparation should focus on why specific accountabilities exist and how transparency, inspection and adaptation lead to better decisions. A candidate who can diagnose a stalled product effort has learned more than someone who can recite event durations without explaining their purpose.

Empiricism requires transparent work and outcomes

The Sprint is a container for focused work that can produce an increment toward the Product Goal. Its fixed length creates a cadence for learning, but the calendar alone does not prove progress. If the team hides unfinished work behind an optimistic status report, stakeholders cannot inspect the real state. Transparency means the Product Backlog, Sprint Backlog and Increment make relevant facts accessible to the people making decisions. This includes acknowledging technical debt, incomplete acceptance criteria and uncertain forecasts. A healthy Scrum Team can say that a desired outcome is not yet achieved without treating that honesty as failure.

The Scrum values of commitment, focus, openness, respect and courage influence how people use the framework. Commitment is not a promise to deliver every estimated item regardless of discovery; it involves dedication to goals and professional work. Courage may mean telling stakeholders that a requested shortcut would compromise the Definition of Done. Respect is visible when developers can challenge assumptions without being punished. These values become practical when organizations create environments where inspection is safe. A team whose performance metrics reward hiding problems will struggle to benefit from Scrum even if it follows every prescribed event.

The Definition of Done establishes a shared quality boundary. An increment that passes local development tests but lacks required integration and security checks may not be usable or releasable. The team should not redefine 'done' to protect the appearance of velocity. If multiple teams work on the same product, consistent quality expectations help ensure their work can be integrated. Distinguish an acceptance condition for a particular backlog item from the broader Definition of Done applying to an increment. Practice deciding what happens when a backlog item is partly built at the end of the Sprint: it does not become a completed increment merely because most tasks were finished.

The Sprint Goal gives developers a coherent purpose and room to adapt implementation. It is not an unordered pile of personal tasks. If an unforeseen technical dependency emerges, developers may adjust the work plan while preserving the intended goal, in collaboration with the Product Owner where scope is affected. A manager who dictates assignments every morning undermines self-management. The Scrum Master should address the underlying impediment rather than mechanically reallocate tasks. The candidate must distinguish legitimate support and facilitation from taking away the team's accountability for organizing its own work.

Understand what each Scrum accountability actually owns

The Product Owner is accountable for maximizing product value and effective Product Backlog management. That includes communicating a clear Product Goal and ordering backlog items so the team can make useful decisions. Stakeholders can contribute ideas, but a committee of voices does not replace one accountable Product Owner. An organization may delegate backlog refinement work while accountability remains clear. If every department assigns competing priorities directly to developers, the team cannot make a meaningful Sprint forecast. The Scrum Master helps the organization understand that the problem is governance and product decision-making, not a shortage of project-management spreadsheets.

Developers are accountable for creating a usable Increment each Sprint, planning how work will be done and adapting their plan toward the Sprint Goal. 'Developers' includes all professionals needed to create the product, not only programmers. Quality engineers, designers or analysts may be part of that accountability depending on the product. A supposedly cross-functional team that must seek approval from an unavailable external specialist for every routine task may struggle to deliver an Increment. The remedy is to address skills and organizational dependencies, not to conceal work in a backlog labeled 'waiting'. Self-management needs an environment where the team can actually exercise responsibility.

The Scrum Master is accountable for the Scrum Team's effectiveness, helping people understand and apply Scrum within the organization. This may involve coaching teams, facilitating when useful, supporting the Product Owner and removing barriers created by policies outside the team's control. It does not grant authority to assign all work, cancel stakeholder feedback or replace the Product Owner's value decisions. In a team with recurring late surprises, the Scrum Master might improve transparency and help members identify hidden dependencies. In a company with rigid release approvals, they might work with leadership to improve the flow of usable increments without abandoning necessary governance.

A common confusion is treating the Scrum Master as the person who must conduct every event. The team owns its inspection and adaptation. The Scrum Master ensures that events are effective and understood, but capable participants should not need a ceremonial chair for every discussion. Consider the Daily Scrum: its purpose is for developers to inspect progress toward the Sprint Goal and adapt the Sprint Backlog, not to report achievements individually to a supervisor. If developers gain no new understanding from it, changing the format may help. The event's purpose matters more than a ritualized sequence of speakers.

Use events to learn something worth acting on

Sprint Planning answers why the Sprint matters, what work might be done and how developers intend to accomplish it. The Product Owner helps explain priority and value, while developers assess capacity and technical needs. A good plan leaves room for discovery; it is a forecast shaped by evidence, not a contract signed against unknown work. If an urgent issue changes the feasible scope, the team should re-evaluate the plan instead of pretending the original list remains perfectly accurate. Understand which decisions emerge from collaboration and which accountability owns each part of the plan.

The Daily Scrum is a short opportunity for developers to adjust work around the Sprint Goal. It can uncover integration problems, duplicated effort or an urgent dependency. The three familiar status questions are not required by the Scrum Guide, and asking them mechanically can disguise the purpose. If developers already coordinate effectively, the event can focus on resolving the next concrete obstacle. A Scrum Master can help address a wider organizational impediment, but should not turn the Daily Scrum into a management inspection. Effective transparency makes the team's own decisions better.

At the Sprint Review, the Scrum Team and stakeholders inspect the outcome and consider what should happen next. It is a working session about product direction, not solely a demonstration that a prescribed list was completed. A new market requirement may change the order of the Product Backlog even when the delivered Increment meets quality criteria. The review provides evidence for product adaptation, while the Product Owner remains accountable for backlog decisions. A useful candidate scenario involves stakeholders discovering that a technically sound feature does not meet user needs; the correct response is adaptation, not hiding the feedback until the next major release.

The Sprint Retrospective concentrates on the team's effectiveness and quality of work. Participants may identify a repeated handoff problem, ambiguous acceptance criteria or excessive context switching. The outcome should include improvements that can actually be pursued, not a list of complaints. Scrum's inspect-and-adapt mechanism becomes weak when retrospective actions never change behavior. Some improvements may involve organizational policy rather than only team practice, making the Scrum Master's wider service important. A candidate should distinguish lessons about product direction, which belong prominently in the review, from improvements to how the team works, which the retrospective helps address.

Prepare with dilemmas rather than memorized rules

Scrum.org currently describes PSM I as an 80-question, 60-minute assessment with an 85% passing score. The focus areas include understanding and applying Scrum, developing people and teams, and managing products with agility. Use the current Scrum Guide and Scrum.org preparation materials for authoritative terminology. Practice assessments can reveal misunderstandings, but repeating the same answer patterns is insufficient if you cannot explain why an appealing alternative would undermine Scrum. Learn the purpose of each commitment and event so a new scenario becomes recognizable even when the wording changes.

Start with a story about a team whose manager assigns tasks daily and grades success by velocity. Identify the Scrum accountability that has been displaced and the transparency problem created by the metric. Propose a supportive change that leaves developers responsible for planning work while giving the organization credible progress evidence. Then introduce an unfinished backlog item near the end of a Sprint and decide whether it can be considered done, how to present the result and what should happen to the remaining work. This tests several concepts together rather than isolating one glossary definition.

For comparison, the PSPO I credential emphasizes effective Product Ownership and value decisions, while PSM I emphasizes understanding and enabling the entire Scrum framework. The responsibilities overlap through shared product goals, but they are not substitutes. A candidate can strengthen PSM thinking by asking what happens when the Product Owner is unavailable, the Definition of Done is ignored or stakeholders demand an impossible fixed scope. Answer with clear accountabilities and empirical evidence, not an assumption that the Scrum Master should personally take control of every problem.

The best Scrum Masters make difficult information easier to confront. They help teams expose incomplete work, invite useful feedback, protect quality and change practices that reduce delivery effectiveness. PSM I preparation should train that judgment. When choosing between exam responses, look for the one that restores transparency, supports real accountabilities and enables inspection and adaptation. That remains the core of Scrum whether a team is building software, improving a service or coordinating complex knowledge work with uncertain requirements.