PSPO I cheat sheet
PSPO I · Keep the key ideas within reach.
Scrum Theory and Empiricism
Scrum is founded on empiricism (knowledge gained from experience and observation) and lean thinking (reduce waste, focus on essentials).
The three empirical pillars are transparency, inspection, and adaptation.
Commitment, Focus, Openness, Respect, and Courage are Scrum's five values; they reinforce the pillars.
Transparency requires a shared standard, such as a Definition of Done, so that inspection is meaningful to everyone observing the artifact.
Inspection must be frequent enough to detect undesirable deviation but not so frequent that it disrupts the work.
Adaptation rule: if any aspect of the process or product deviates outside acceptable limits, adjust as soon as possible.
Empiricism suits complex work: more is unknown than known, so predictive forecasts are replaced by short inspect-and-adapt cycles.
Scrum combines iterative (refining and reworking) and incremental (adding to a usable whole) approaches within every Sprint.
The Scrum Framework and Accountabilities
Scrum defines three accountabilities: Product Owner, Scrum Master, and Developers, forming one Scrum Team of ten or fewer with no sub-teams or hierarchies.
Product Owner: accountable for maximizing value and for effective Product Backlog management, including ordering and transparency.
Scrum Master: accountable for the Scrum Team's effectiveness; serves the team, the Product Owner, and the organization; causes impediments to be removed.
Developers: accountable for the Sprint Backlog and for creating a usable Increment each Sprint; they are self-managing and cross-functional.
Five events: Sprint, Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective; all except the Sprint itself are contained within it.
Sprint rule: fixed length of one month or less; no changes that endanger the Sprint Goal; scope may be clarified with the Product Owner; quality never decreases.
Timeboxes for a one-month Sprint: Planning 8h, Daily Scrum 15 min, Review 4h, Retrospective 3h; shorter Sprints scale these down.
Three artifacts and their commitments: Product Backlog (Product Goal), Sprint Backlog (Sprint Goal), Increment (Definition of Done).
Definition of Done: formal quality standard for the Increment; work that does not meet it is not part of the Increment.
Product Ownership and Delivering Value
The Product Owner is one person, not a committee; only the Product Owner changes Product Backlog content and order.
The Product Owner may delegate backlog work to others but remains accountable for the Product Backlog and for maximizing value.
Product management is a function the Product Owner performs; it is not the same as a project manager role.
No one outside the Scrum Team may instruct Developers to work from a different set of requirements; the Product Backlog is the single source of work.
Value is subjective and realized as outcomes; it is measured by impact on users and customers, not by counting output.
Product Owner decisions are made visible through the ordering and content of the Product Backlog, not through separate documents.
The Product Owner does not direct how Developers build the Increment; Developers self-manage the technical work and work plan.
Product Backlog Management
Product Backlog: an emergent, ordered list of everything needed to improve the product; it is never complete.
Item attributes: description, order, and size or estimate; detail grows as understanding grows.
Ordering rule: higher-ordered items are clearer, more detailed, and more valuable; ordering maximizes value delivered.
Refinement is ongoing: break items down into smaller, more precise ones so top-ordered items are ready for the next Sprint.
Product Goal is the commitment attached to the Product Backlog: a long-term objective describing a future state of the product.
Sprint Backlog = Sprint Goal + selected Product Backlog items + the plan for delivering them; the Developers create it during Sprint Planning.
During the Sprint, only the Developers add or change work in the Sprint Backlog.
The Sprint Goal may change only if the work turns out differently than expected; scope may be renegotiated with the Product Owner.
Stakeholders, Customers and Product Strategy
Sprint Review is the primary inspect-and-adapt event with stakeholders; it is a working session, not a status report or approval gate.
Stakeholders are anyone with interest in or influence over the product; the Product Owner is their main point of contact.
Value is realized only when the Increment reaches users; frequent releases shorten the feedback loop and generate evidence.
Strategy cascade: vision (why) → Product Goal (future state) → Sprint Goal (one Sprint) → Increment (delivered value).
Sprint Review invites customers and stakeholders to collaborate on what to do next, and the Product Backlog may be re-ordered as a result.
Release timing is a business decision weighed by the Product Owner against feedback needs, delivery cost, and risk.