SM cheat sheet

Scrum is founded on empiricism: knowledge comes from experience and decisions are made on what is observed.

Three empirical pillars: transparency (work and state visible), inspection (frequent checks of artifacts and progress), adaptation (adjust course when results fall outside limits).

Lean thinking contributions to Scrum: eliminate waste, limit work in progress, deliver value continuously, respect people, and optimize the whole.

Five Scrum values: Commitment, Focus, Openness, Respect, Courage - behavior expectations that make empiricism viable.

Iterative and incremental: deliver usable increments each Sprint so risk is reduced and feedback is fast.

Transparency requires a shared definition of work quality; without it, inspection produces misleading conclusions.

Inspection without adaptation is waste; adaptation must occur as soon as a deviation is detected, and quickly.

Self-managing teams choose how to do the work; Scrum defines the boundaries and accountabilities, not the tactics.

One Scrum Team is typically 10 or fewer people; smaller teams communicate better and are more productive.

Three accountabilities: Product Owner (value), Scrum Master (effectiveness), Developers (creating the increment).

The Scrum Team is cross-functional: it holds all skills needed to create value each Sprint.

The Scrum Team is self-managing: it decides internally who does what, when, and how.

Product Owner is one person, not a committee; the PO may delegate work but remains accountable.

Scrum Master serves the team and organization by coaching, teaching, removing impediments, and ensuring Scrum is understood and enacted.

Developers own the Sprint Backlog, the Definition of Done quality standard, and adapting their plan daily.

The whole team is accountable for the increment; there are no sub-teams or hierarchies within the Scrum Team.

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

Sprint is fixed length, one month or less, with no changes that endanger the Sprint Goal; scope may be clarified with the PO.

Sprint Planning answers: Why is this Sprint valuable (Sprint Goal), What can be done (selection), How will the work get done (plan).

Daily Scrum is a 15-minute event for Developers to inspect progress toward the Sprint Goal and adapt the Sprint Backlog.

Sprint Review inspects the outcome with stakeholders and determines future adaptations; it is a working session, not a status report.

Sprint Retrospective inspects individuals, interactions, processes, tools, and Definition of Done, and identifies the most helpful improvements.

Each event is a formal opportunity to inspect and adapt; skipping an event loses transparency and inspection.

Events are timeboxed; the Sprint is the only event with a variable length up to one month.

Three artifacts: Product Backlog, Sprint Backlog, Increment - each carries a commitment for transparency.

Product Backlog commitment is the Product Goal: a long-term objective describing a future state of the product.

Sprint Backlog commitment is the Sprint Goal: the single objective for the Sprint, providing focus and flexibility.

Increment commitment is the Definition of Done: the quality standard the increment must meet to be usable.

Product Backlog is an emergent, ordered list of what improves the product; the PO orders it and may reorder at any time.

Sprint Backlog is composed of the Sprint Goal, selected Product Backlog items, and the plan to deliver them; it is updated as learning occurs.

An Increment is a concrete stepping stone toward the Product Goal; multiple increments may be produced within one Sprint.

Work that does not meet the Definition of Done is not part of the Increment and is not presented at the Sprint Review.

Facilitation stance: make the process visible, hold the timebox, and let the team own content decisions.

Coaching moves through observation, questioning, and feedback; directive advice is used only when the team lacks knowledge.

Useful formats: silent brainstorming, dot voting, fist-of-five, 1-2-4-all, and check-in/check-out.

Retrospective structure: set the stage, gather data, generate insights, decide what to do, close.

A coach intervenes on process and dynamics, not on technical solutions the Developers are accountable for.

Powerful questions are open, short, and assume the other person is capable of finding the answer.

Visible information radiators (task boards, burn charts, impediment lists) enable inspection without status meetings.

Group decision rules: consent (no reasoned objection) is faster than consensus (everyone agrees).

Servant leadership: the leader's priority is the growth and effectiveness of the people served, not command and control.

Scrum Master serves three groups: the Scrum Team, the Product Owner, and the organization.

Impediment handling: make it visible, identify who can remove it, and escalate only when the team cannot resolve it.

Stakeholder engagement is continuous: Sprint Review is the formal inspect-and-adapt point with stakeholders.

The PO is the single point of contact for stakeholder requests; the Scrum Master protects the team from direct disruption.

Change resistance is addressed by inviting participation, making the reason for change visible, and starting small.

Coaching the organization means teaching Scrum's principles to leaders and helping remove structural barriers.

Boundary spanning: the Scrum Master connects the team to the wider organization while shielding it from interruptions that break focus.