SMP cheat sheet
SMP · Keep the key ideas within reach.
Scrum Theory and Principles
Scrum is founded on empiricism: knowledge comes from experience and decisions are based on observation of the actual work.
Three empirical pillars: transparency, inspection and adaptation; all three must be present for empirical process control to work.
Transparency requires a shared standard so that inspectors and stakeholders interpret artifacts the same way.
Inspection must be frequent enough to detect deviation but not so frequent that it interferes with the work itself.
Adaptation should happen as soon as possible; if any aspect of the process or artifacts falls outside acceptable limits, adjust it.
Five Scrum values: commitment, focus, openness, respect and courage; they guide behavior and build trust.
Lean thinking in Scrum: eliminate waste, focus on essentials, respect people and deliver value continuously.
Iterative and incremental delivery maximizes feedback opportunities and reduces risk before large investments are made.
Decision rule: when a deviation is found during inspection, adapt the process or artifact rather than accepting the deviation.
Scrum Roles and Accountabilities
Scrum defines three accountabilities: Product Owner, Scrum Master and Developers; there are no sub-teams or hierarchies.
Product Owner is accountable for maximizing product value and for effective Product Backlog management, including ordering.
Scrum Master is accountable for the Scrum Team's effectiveness, coaching the team and organization and removing impediments.
Developers are accountable for creating a usable Increment each Sprint and decide internally who does what, when and how.
The Product Owner is one person, never a committee; work may be delegated but accountability remains with the Product Owner.
Scrum Master is a true leader who serves the Scrum Team and the wider organization rather than a project manager or task assigner.
Decision rule: the Product Owner orders the Product Backlog; the Developers determine how much work enters the Sprint Backlog.
Only the Product Owner may cancel a Sprint, and only when the Sprint Goal becomes obsolete.
Scrum Events
Five events: Sprint (the container), Sprint Planning, Daily Scrum, Sprint Review and Sprint Retrospective.
A Sprint is fixed length, one month or less, and a new Sprint starts immediately after the previous Sprint ends.
Sprint Planning addresses three topics: why the Sprint is valuable (Sprint Goal), what can be done, and how the work will be done.
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 of the Sprint and determines future adaptations; timebox up to four hours for a one-month Sprint.
Sprint Retrospective plans ways to increase quality and effectiveness; timebox up to three hours for a one-month Sprint.
Sprint Planning timebox is up to eight hours for a one-month Sprint; shorter Sprints reduce the timeboxes proportionally.
Events create regularity and minimize the need for meetings not defined in Scrum.
Decision rule: if the Sprint Goal becomes obsolete, the Product Owner may cancel the Sprint; otherwise the Sprint runs to its timebox.
Scrum Artifacts and Commitments
Three artifacts: Product Backlog, Sprint Backlog and Increment; each artifact has one commitment attached to it.
Product Backlog commitment is the Product Goal: a long-term target for the Scrum Team, with only one active at a time.
Sprint Backlog commitment is the Sprint Goal: a single objective that provides focus and guides the Developers' work.
Increment commitment is the Definition of Done: a formal description of quality the Increment must meet.
Product Backlog is an emergent, ordered list of what is needed to improve the product; it is the single source of work.
Sprint Backlog is composed of the Sprint Goal, selected Product Backlog items and a plan for delivering the Increment.
An Increment is a concrete, usable stepping stone toward the Product Goal; it must be usable to provide value.
Decision rule: if an item does not meet the Definition of Done, it is not part of the Increment and cannot be released.
If the organizational Definition of Done is a minimum standard, teams may add stricter criteria but may not relax it.
Coaching and Facilitation
Coaching stance: ask before telling; questions raise self-awareness and ownership more reliably than instructions.
Facilitation means designing and guiding group processes to reach a defined outcome while staying neutral on content.
Decision rule: facilitate when the group can solve the problem; teach or mentor when a skill gap exists; coach for personal growth.
Powerful questions are open, concise and invite reflection; leading or yes/no questions reduce ownership.
Psychological safety is a precondition for honest inspection; facilitation should protect equal voice and dissent.
Retrospective facilitation typically moves through data gathering, insight generation and decision on actions.
Conflict handling: address behavior and interests rather than personalities, using structured formats to depersonalize.
Distinguish impediments the team can remove itself from those needing organizational action and escalation.
Servant Leadership and Team Development
Servant leadership prioritizes the growth, needs and effectiveness of others; the leader removes impediments rather than directing work.
Tuckman stages: forming, storming, norming, performing, with adjourning when a team disbands.
Situational leadership: match direction and support to the person's competence and commitment for the specific task.
Psychological safety, the shared belief that speaking up is safe, predicts learning behavior and team performance.
Self-managing teams require clear goals, explicit boundaries and real decision authority to function.
Decision rule: give more structure and direction to new teams and more autonomy as capability and trust grow.
Delegation rule: delegate when competence and commitment are high; increase direction or support when either is low.
Protect the team from interruptions while ensuring it still receives direct stakeholder feedback.
Product Delivery and Value Maximization
Value is realized when Increments are released and used; delivered value is an outcome, not a count of completed items.
Little's Law: average cycle time equals work in progress divided by throughput; limiting WIP shortens cycle time if throughput holds.
Flow metrics to monitor: cycle time, throughput and work in progress; rising WIP predicts longer delivery times.
Cost of delay expresses the economic impact of late delivery and supports ordering the Product Backlog by value.
The Sprint Goal should express a single valuable outcome rather than a list of separate tasks.
Work that does not meet the Definition of Done is undone work and accumulates as debt, reducing transparency.
Decision rule: an Increment may be released only when it meets the Definition of Done; release frequency is a business decision.
The Product Owner orders the Product Backlog using value, risk, dependencies and cost of delay as criteria.
Organizational Agility and Scaling
Scrum is a framework for a single Scrum Team; scaling frameworks add coordination practices but are not Scrum itself.
Nexus applies to three to nine Scrum Teams working on one product, with a Nexus Integration Team addressing cross-team integration.
Dependencies between teams are the primary scaling constraint; they must be made visible and minimized.
Decision rule: scale only when a single team cannot deliver the product; extra teams add coordination cost and dependencies.
When several teams build one product, they share one Product Backlog, one Product Owner and one Product Goal.
Structure the organization around products and value streams rather than functional handoffs to reduce coordination overhead.
Empirical process control at scale requires integration, a shared Definition of Done and a single integrated Increment.
Agile transformation is a change in operating model and leadership behavior, not a process rollout or tool installation.