Scrum Master PSM I Prep

This deck is designed to help you build a solid foundation in Scrum fundamentals as you prepare for the Professional Scrum Master I (PSM I) assessment. The cards walk through the origins of the framework, its underlying principles of empirical process control, and the three pillars that hold the whole approach together. You'll also review the core accountabilities within a Scrum Team, including the Product Owner, Scrum Master, and Developers, along with questions that probe the nuances of how these roles interact.

It's well suited for anyone new to Agile or Scrum who wants to earn the PSM I credential, whether you're a practicing Scrum Master, a team member transitioning into a facilitation role, or a coach building credibility with stakeholders. The questions range from straightforward definitions to tricky scenarios about role boundaries and team structure, which mirrors the style of the actual certification exam.

To get the most out of these cards, try short, frequent review sessions rather than cramming, since spaced repetition helps the Scrum terminology and role distinctions stick in long-term memory. When you encounter a card you keep missing, pause and re-read the relevant section of the Scrum Guide before moving on, because many of the trickier questions depend on a precise understanding of the official wording. Finally, try to connect each concept to a real team situation you've experienced or can imagine, as this makes the abstract principles much easier to recall under exam pressure.

Scrum is a lightweight framework designed to help teams deliver value iteratively and incrementally when solving complex problems. Its primary purpose is to enable teams to be productive and creative while delivering the highest possible value from their work. The framework was originally created by Ken Schwaber and Jeff Sutherland, who first presented it publicly at the OOPSLA conference in 1995. The name itself was borrowed from the sport of rugby and was popularized in a 1986 Harvard Business Review article by Hirotaka Takeuchi and Ikujiro Nonaka, who used the rugby scrum as a metaphor for a holistic, team-based approach to product development. Today, the definitive definition of Scrum lives in the Scrum Guide, authored by Schwaber and Sutherland, which establishes the rules of the framework.

At the heart of Scrum is empirical process control, a decision-making approach that relies on observation, experimentation, and learning from experience rather than on a rigid, upfront-defined process. Empirical process control rests on three pillars: transparency, inspection, and adaptation. Transparency requires that significant aspects of the process be visible to both those performing the work and those receiving it. Inspection means that Scrum artifacts and progress toward the agreed Sprint Goal are examined frequently and diligently. Adaptation requires that, when any aspect deviates outside acceptable limits, the process itself be adjusted promptly to minimize further deviation. Together, these three pillars create a continuous feedback loop that allows teams to navigate complexity and uncertainty.

A Scrum Team is intentionally small and is composed of exactly three accountabilities: one Product Owner, one Scrum Master, and the Developers who do the work of delivering a valuable Increment. The optimal size is ten or fewer people, which is small enough to remain nimble while being large enough to complete meaningful work within a Sprint. The team is designed to be both self-managing and cross-functional. A self-managing team internally decides who does the work, how it gets done, and how to turn the Product Backlog into Increments. A cross-functional team possesses all the skills needed to deliver a valuable Increment without depending on people outside the team, which reduces handoffs and waiting time.

The Product Owner's primary responsibility is to maximize the value of the product resulting from the work of the Scrum Team. To be effective, one Product Owner must be assigned to one Scrum Team, although they may represent the interests of many stakeholders. The Scrum Master's primary accountability is to establish Scrum as defined in the Scrum Guide, remove impediments, and coach both the team and the organization. Within a single Scrum Team, the Product Owner and Scrum Master are separate accountabilities and cannot be combined into one person, and the Scrum Master also cannot simultaneously serve as a Developer. These boundaries preserve clarity of purpose and the system of checks and balances that allows empirical decision-making to flourish.

The Sprint is the heart of Scrum: a fixed time-box of one month or less during which a done Increment is created. The Sprint length remains fixed once the Sprint begins and cannot be changed or extended, which creates a stable cadence for inspection and adaptation. Every Sprint is guided by a single Sprint Goal that gives the team a specific focus and encourages unity of effort. Only the Product Owner has the authority to cancel a Sprint, and they typically do so when the Sprint Goal becomes obsolete, such as when market conditions or strategic direction shifts. If a Sprint is cancelled, any completed Product Backlog items are reviewed and may be accepted into the baseline for future reference, ensuring that finished work is not lost.

Scrum defines five events that structure each Sprint. Sprint Planning defines the work to be performed and produces the Sprint Backlog; for a one-month Sprint, it is time-boxed to a maximum of eight hours and addresses three topics: why the Sprint is valuable, what can be done, and how the chosen work will be accomplished. The Daily Scrum is a fifteen-minute event for Developers to inspect progress toward the Sprint Goal and adapt the plan for the next day of work; only Developers are required to attend, and the output is an updated plan rather than a status report. The Sprint Review is a working meeting at the end of the Sprint, time-boxed to four hours for a one-month Sprint, where the team inspects the Increment and adapts the Product Backlog with stakeholders. The Sprint Retrospective, time-boxed to three hours for a one-month Sprint, is the team's opportunity to inspect and improve their process, relationships, tools, and Definition of Done. A new Sprint begins immediately after the previous Sprint's Retrospective concludes, keeping the cadence unbroken.

Scrum defines three artifacts, each of which is designed to provide transparency and opportunities for inspection and adaptation. The Product Backlog is an ordered, emergent list of what is needed to improve the product, and it is the single source of work undertaken by the Scrum Team. It is owned by the Product Owner, who is responsible for its content, availability, and ordering, and the items within it can be described with three attributes: value, risk or uncertainty, and effort. The Product Backlog is committed to a long-term Product Goal, which describes a future state of the product and gives the team a strategic direction. To keep the Product Backlog healthy, the team engages in ongoing refinement, adding detail, estimates, and order to items; this activity typically consumes no more than ten percent of the Developers' capacity.

The Sprint Backlog is the set of Product Backlog items selected for the current Sprint, plus the plan to deliver them and the Sprint Goal. It is owned by the Developers, who update it throughout the Sprint as they learn more about the work. The Increment is a concrete stepping stone toward the Product Goal, representing the sum of all Product Backlog items completed during a Sprint plus the value of all previous Increments, and a team should produce at least one Increment per Sprint and often more if it is useful. Each Increment must satisfy the team's Definition of Done, a shared understanding of what it means for work to be complete. The Definition of Done typically includes activities such as code review, testing, integration, documentation, and potentially release to production, and it is a shared commitment of the entire Scrum Team rather than the responsibility of any single role. The Sprint Goal is the commitment associated with the Sprint Backlog, while the Definition of Done is the commitment associated with the Increment, and together these commitments make progress and quality visible.

Estimating in Scrum is grounded in the principle of relative sizing, where items are compared to one another rather than estimated in absolute units of time. The most common unit of measure is the Story Point, which expresses an estimate of the overall effort required to fully implement a Product Backlog item. Because Developers will do the work, they are the ones who decide how many story points to assign. Teams often use the Fibonacci sequence, with values such as 1, 2, 3, 5, 8, 13, 21, and so on, because the widening gaps reflect growing uncertainty for larger items and force meaningful conversation when estimates diverge. Planning Poker is a popular consensus-based technique that uses these numbered cards, with team members discussing and re-voting until the group converges on a shared estimate.

When uncertainty is high, teams use a spike, a time-boxed investigation or experiment designed to reduce uncertainty about a technical or functional question before committing to a larger estimate. To track progress, Scrum teams use several complementary visualizations. Velocity is an empirical measure of how much Product Backlog work a team turns into a done Increment during a Sprint, and while it measures the amount of work, it is not a direct measure of productivity or value. A burndown chart shows the work remaining over time and is often used during a Sprint for the Sprint Backlog, while a burnup chart shows work completed over time and frequently includes a target line for scope. At a higher level, a Release Burndown tracks remaining work toward a release, and a Cumulative Flow Diagram (CFD) shows cumulative work across statuses over time, making bottlenecks visible.

The Scrum Master is accountable for the effectiveness of the Scrum Team, for ensuring that the team follows Scrum, for removing impediments, and for making sure the events are held and productive. Despite the leadership the role demands, the Scrum Master is not a project manager; Scrum has no project manager role. Many Scrum Masters also act as agile coaches, but the role fundamentally combines facilitating, serving, and leading within the organization. The underlying leadership philosophy is servant leadership, in which the leader's primary goal is to serve others by focusing on the team's needs. A core Scrum Master skill is facilitation: guiding meetings and processes without exercising authority over content, which keeps decision-making in the hands of the team.

The Scrum Master serves the three accountabilities in distinct ways. With the Product Owner, the Scrum Master helps find techniques for effective Product Backlog management, facilitates collaboration with stakeholders, and supports empirical planning. With the Developers, the Scrum Master coaches self-management and cross-functionality, removes impediments, ensures that events are productive, and protects the team from external interference. With the organization, the Scrum Master leads, trains, and coaches adoption, plans implementations, and helps employees understand empiricism. Removing impediments is a primary responsibility, although the entire team should help surface and address them; an impediment is anything that prevents the team from making progress toward the Sprint Goal. Distinguishing a risk, which is a potential future problem, from an issue, which is a current problem, helps the Scrum Master prioritize where to focus effort.

When multiple Scrum Teams work on the same product, they need additional coordination. A Scrum of Scrums is a lightweight technique in which representatives from each team meet to coordinate their work, while Nexus is a more comprehensive framework that adds events and artifacts to scale Scrum across multiple teams while preserving a single Product Backlog. Beyond scaling, Scrum benefits from a number of supporting practices and concepts. A Minimum Viable Product (MVP) is a version of a new product that allows a team to collect the maximum amount of validated learning with the least effort, embodying the empirical mindset Scrum is built on. The cost of change curve in Scrum is relatively flat because feedback is frequent and rework happens early, which is one of the main ways Scrum reduces risk. A release is a version of the product made available to end users, and a potentially shippable product increment is one that meets the Definition of Done and is theoretically ready for release at any time.

Scrum also redefines how teams and stakeholders relate. A stakeholder is anyone with an interest in the product or project, while a user is a specific type of stakeholder who actually uses the product. The role of management is to support the Scrum Team with resources, environment, and alignment rather than to direct the work, since command-and-control leadership conflicts with Scrum's empirical and self-managing approach. The classic chicken-and-pig metaphor captures this distinction: pigs, meaning the Product Owner, Scrum Master, and Developers, are committed and accountable for delivery, while chickens, including stakeholders and managers, are involved but not accountable. Teams are encouraged to be feature teams organized around delivering end-to-end customer value, rather than component teams organized around a single technical layer, and to pursue a single piece of flow by minimizing work in progress to reduce context switching. Poor Definition of Done tends to accumulate technical debt, the implied cost of choosing an easy solution today over a better but slower one, which is why Scrum insists on transparency about quality. Together, these concepts reinforce the empirical, value-driven foundation of the framework.