CSM cheat sheet

Scrum is founded on two foundations: empiricism (knowledge comes from experience, decisions are based on what is observed) and lean thinking (reduce waste, focus on essentials).

The three empirical pillars are transparency, inspection, and adaptation; they form a chain - transparency enables inspection, inspection enables adaptation.

Transparency requires a shared standard so that inspectors and the people doing the work interpret the artifact the same way; low transparency produces decisions that diminish value.

Inspection must be frequent enough to detect unwanted variance but must not disrupt the work being inspected; the Scrum events are where inspection is formalized.

Adaptation rule: if any aspect of the process deviates outside acceptable limits, the process or the produced material is adjusted as soon as possible to limit further deviation.

The five Scrum values are commitment, focus, openness, respect, and courage; their presence or absence determines how well the three pillars function.

Scrum is purposefully incomplete: it defines only the parts needed to implement its theory and does not prescribe detailed techniques, so teams add practices that fit their context.

Scrum is lightweight, simple to understand, and difficult to master; it is a framework, not a process or a methodology with prescribed techniques.

The Scrum Team consists of one Product Owner, one Scrum Master, and Developers; there are no sub-teams or hierarchies, and the team is typically 10 or fewer people.

Product Owner is accountable for maximizing product value and for effective Product Backlog management: developing and communicating the Product Goal, creating and communicating items, ordering items, and ensuring the backlog is transparent, visible, and understood.

The Product Owner is one person, not a committee; the PO may delegate work but remains accountable, and the entire organization must respect their decisions.

Scrum Master is accountable for establishing Scrum as defined in the Scrum Guide and for the Scrum Team's effectiveness, serving as a true leader who serves the team, the PO, and the organization.

Developers are accountable for creating any aspect of a usable Increment each Sprint, instilling quality by adhering to the Definition of Done, adapting the plan daily toward the Sprint Goal, and holding each other accountable as professionals.

Scrum Master service to the organization includes leading, training, and coaching in Scrum adoption, planning and advising implementations, and removing barriers between stakeholders and Scrum Teams.

The Scrum Master causes the removal of impediments and ensures all Scrum events take place, are positive, productive, and kept within the timebox.

The entire Scrum Team is accountable for creating a valuable, useful Increment every Sprint; value results from the PO's ordering combined with the Developers' work.

There are exactly five events: the Sprint (the container event) and, within it, Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective.

A Sprint is fixed at one month or less; a new Sprint starts immediately after the previous Sprint ends, and its length cannot be shortened or lengthened.

Sprint Planning addresses three topics - why (Sprint Goal), what (items selected from the Product Backlog), and how (the plan) - with a timebox of 8 hours or less for a one-month Sprint.

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

The Sprint Review is the second-to-last event; the Scrum Team and stakeholders inspect the Sprint outcome and determine future adaptations, with a timebox of 4 hours for a one-month Sprint.

The Sprint Retrospective is the final event of the Sprint; the team inspects individuals, interactions, processes, tools, and the Definition of Done, then plans improvements, timeboxed to 3 hours for a one-month Sprint.

Only the Product Owner may cancel a Sprint, and only when the Sprint Goal becomes obsolete; cancellation is rare and consumes time and effort.

Events create regularity and minimize the need for meetings not defined in Scrum; shorter Sprints scale the timeboxes down proportionally.

There are three artifacts - Product Backlog, Sprint Backlog, and Increment - and each carries one commitment: Product Goal, Sprint Goal, and 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 Sprint Backlog is composed of the Sprint Goal (why), the selected Product Backlog items (what), and the plan for delivering them (how); it belongs to and is managed by the Developers.

The Increment is a concrete stepping stone toward the Product Goal; each Increment is additive to prior increments and must be usable in order to provide value.

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

If the organization has a standard Definition of Done, all Scrum Teams must follow it at minimum; if not, the Scrum Team creates one appropriate to the product.

The Product Goal is a long-term target for the Scrum Team to plan against; it lives in the Product Backlog and must be fulfilled or abandoned before the next one is set.

The Sprint Goal is the single objective for the Sprint, committed to by the Developers; it creates coherence and focus while allowing flexibility on the exact work needed.