Professional Scrum Master I (PSM I) cheat sheet

Scrum is founded on empiricism and lean thinking; empiricism asserts that knowledge comes from experience and that decisions are made on observation.

The three empirical pillars are transparency, inspection, and adaptation; weakening any one of them undermines the other two.

Transparency requires that the emergent process and the work be visible to those performing it and those receiving it; low transparency produces decisions that reduce value and increase risk.

Inspection must be frequent enough to detect unwanted variance but not so frequent that it interferes with the work being inspected.

Adaptation follows inspection: the process, or the products being produced, is adjusted when results fall outside acceptable limits.

The four formal inspect-and-adapt events are Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective; the Sprint is the container event for all of them.

The five Scrum values are commitment, focus, openness, respect, and courage; they shape behavior and build the trust on which empiricism depends.

Lean thinking in Scrum means reducing waste and focusing on the essentials; the Product Backlog is pruned of work that does not add value.

The Scrum Team consists of one Scrum Master, one Product Owner, and Developers; it has 10 or fewer people and no sub-teams or hierarchies.

The Scrum Team is cross-functional (it has all skills needed to create value each Sprint) and self-managing (it decides who does what, when, and how).

The Product Owner is accountable for maximizing the value of the product and for effective Product Backlog management; the role is held by one person, not a committee.

The Scrum Master is accountable for the Scrum Team's effectiveness, coaching self-management and helping the team improve its practices.

The Scrum Master serves the Product Owner by helping find techniques for defining the Product Goal and managing the Product Backlog, and by facilitating stakeholder collaboration.

The Scrum Master serves the organization by leading Scrum adoption, advising on implementation, and removing barriers between stakeholders and Scrum Teams.

Developers create the Sprint Backlog, instill quality by adhering to the Definition of Done, adapt their plan daily, and hold each other accountable.

The whole Scrum Team is accountable for creating a valuable, useful Increment every Sprint; individual accountabilities exist, but the result is shared.

The Sprint is a fixed-length event of one month or less; a new Sprint starts immediately after the conclusion of the previous one, with no gap between them.

Sprint Planning has a maximum of 8 hours for a one-month Sprint and addresses why the Sprint is valuable (Sprint Goal), what can be done, and how the work will be done.

The Daily Scrum is a 15-minute event for Developers, held every working day at the same time and place, to inspect progress toward the Sprint Goal and adapt the Sprint Backlog.

The Sprint Review has a maximum of 4 hours for a one-month Sprint; the Scrum Team presents results to key stakeholders and the Product Backlog is updated.

The Sprint Retrospective has a maximum of 3 hours for a one-month Sprint and closes the Sprint by identifying the most helpful improvements.

Shorter Sprints generate more learning cycles and limit risk; event timeboxes scale down proportionally for shorter Sprints.

Only the Product Owner can cancel a Sprint, and only when the Sprint Goal becomes obsolete.

The Daily Scrum is not the only time Developers may adapt their plan; they can meet as often as needed throughout the day.

There are three artifacts: Product Backlog, Sprint Backlog, and Increment; each carries a commitment, namely the Product Goal, the Sprint Goal, and the Definition of Done respectively.

The Product Backlog is an emergent, ordered list of what is needed to improve the product; it is the single source of work undertaken by the Scrum Team.

The Product Goal describes a future state of the product and serves as a long-term target; it must be fulfilled or abandoned before the next Product Goal is taken on.

The Sprint Backlog is composed of the Sprint Goal, the Product Backlog items selected for the Sprint, and the plan for delivering them; it is updated throughout the Sprint.

An Increment is a concrete stepping stone toward the Product Goal; work cannot be considered part of an Increment unless it meets the Definition of Done.

The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product.

If the Definition of Done is an organizational standard, all Scrum Teams must follow it as a minimum; if not, the Scrum Team creates its own.

Multiple Scrum Teams working on the same product share the same Product Owner, Product Backlog, Product Goal, and Definition of Done.

Timeboxes are maximum durations; an event may end early but must never exceed its allotted timebox.

A Sprint may not exceed one month; shorter Sprints reduce risk, but no Sprint may run longer than the maximum.

During a Sprint, no change is permitted that would endanger the Sprint Goal, and quality goals do not decrease.

Sprint scope may be clarified and renegotiated with the Product Owner as more is learned, without altering the Sprint Goal.

The Scrum Master ensures that all Scrum events take place and are positive, productive, and kept within the timebox.

If the Sprint Goal becomes obsolete, the Product Owner may cancel the Sprint; completed and Done items are reviewed and potentially released.

There is exactly one Product Owner per product; the Product Owner may delegate work but remains accountable for the outcome.

Scrum is a lightweight framework that is intentionally incomplete; it defines only what is required to implement Scrum theory, leaving techniques to the people using it.

Scrum can be used to develop products, services, and other complex work; it is not limited to software.

Scrum employs an iterative, incremental approach to optimize predictability and to control risk.

Adopting Scrum requires changes to organizational structure, processes, and practices; there is no single prescribed path or rollout sequence.

Implementations typically start with a small, willing team and expand iteratively, learning from each cycle of inspection and adaptation.

The Scrum Guide does not prescribe engineering practices, tools, or techniques; teams select practices that fit their context and satisfy the Definition of Done.

Because self-management shifts authority, organizations commonly need leadership support and adjustments to budgeting, governance, and people practices.