PECB Certified PSM Basic cheat sheet

Scrum is founded on empirical process control: decisions rest on observation, experience, and experimentation rather than upfront prediction.

The three empirical pillars are transparency, inspection, and adaptation; weakening any one pillar undermines the others.

Transparency requires a shared definition of done and a common standard so inspectors interpret artifacts the same way.

Inspection must be frequent enough to detect deviation but not so frequent that it disrupts the work being inspected.

Adaptation follows inspection: if a resulting process or product falls outside acceptable limits, the process or material must be adjusted.

The five Scrum values are commitment, focus, openness, respect, and courage; they guide behavior rather than prescribe process steps.

Iterative development refines a product through repeated cycles; incremental development adds completed, usable pieces to it.

The Scrum Guide is deliberately incomplete: it defines the framework's rules but leaves techniques and practices to the team.

Three accountabilities exist: Product Owner (product value), Scrum Master (framework effectiveness), and Developers (creating the Increment).

The Scrum Team is one self-managing unit of ten or fewer people; large groups should split into multiple coherent Scrum Teams.

Five events: the Sprint (container), Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective.

Four formal events occur inside the Sprint; the Sprint itself is the fifth event and has a fixed length of one month or less.

Three artifacts: Product Backlog, Sprint Backlog, and Increment; each has a commitment (Product Goal, Sprint Goal, Definition of Done).

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

Sprint Planning addresses why (Sprint Goal), what (selected backlog items), and how (plan); timebox is eight hours or less for a one-month Sprint.

The Sprint Review inspects the outcome and determines future adaptations; the Retrospective plans ways to increase quality and effectiveness.

Artifacts are inspected at events; the Product Backlog is refined continuously and the Increment is inspected at the Sprint Review.

The Scrum Master serves the Scrum Team by coaching self-management, helping focus on high-value increments, and removing impediments to progress.

The Scrum Master serves the Product Owner by helping find techniques for effective Product Goal definition and Product Backlog management.

The Scrum Master serves the organization by leading adoption, planning and advising Scrum implementations, and removing barriers between stakeholders and teams.

Servant leadership inverts the hierarchy: the leader's primary outcome is the growth and well-being of the people served.

The Scrum Master is not a project manager, does not assign tasks, and holds no authority to command Developers' technical choices.

Coaching stance: ask questions that surface the team's own options rather than supplying answers, so ownership stays with the team.

Impediment handling distinguishes team-resolvable issues from organizational blockers; the latter are escalated with evidence, not blame.

Teaching, facilitating, mentoring, and coaching are distinct stances; the Scrum Master selects the stance matching the situation.

Product Backlog ordering uses value, risk, dependencies, and size; the Product Owner is accountable for the order, Developers for the estimates.

Backlog refinement is an ongoing activity, not a formal event; it keeps upcoming items small enough to be ready within one Sprint.

Sprint Goal provides coherence; if the work turns out different than expected, scope may be renegotiated with the Product Owner as more is learned.

Definition of Done is a formal quality gate; an item is not an Increment until it meets it, and the DoD is tightened when possible.

Velocity is a planning aid derived from past Increments, never a target or performance measure imposed on the team.

Estimation is done by the people doing the work; relative sizing (story points, ideal days) is a tool, not a mandate.

Sprint cancellation is rare and only the Product Owner may cancel; it happens when the Sprint Goal becomes obsolete.

Scaling starts with well-functioning single teams; adding a shared Product Backlog and a common Definition of Done precedes adding coordination roles.

Metrics that support empiricism include Sprint Goal achievement, cycle time, and escaped defects; output counts alone do not show value.