PSPO I study materials
PSPO I study resources

PSPO I cheat sheet

PSPO I · Keep the key ideas within reach.

Quick reference

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.

Quick reference

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.

Quick reference

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.

Quick reference

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.

Quick reference

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.