CSPO cheat sheet

Scrum is a lightweight framework defined by the Scrum Guide: three accountabilities (Product Owner, Scrum Master, Developers), five events, three artifacts, and the rules binding them.

The five events are Sprint, Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective; all occur inside the Sprint, which is a fixed-length container of 1 month or less.

The three artifacts are Product Backlog, Sprint Backlog, and Increment; each has a commitment: Product Goal, Sprint Goal, and Definition of Done respectively.

The three empirical pillars are transparency, inspection, and adaptation; Scrum implements them through its events, which create regularity and minimize meetings not defined by Scrum.

The Scrum Team is one self-managing unit of 10 or fewer people, with no sub-teams or hierarchies; the Scrum Master and Product Owner also work within the team.

Sprint Planning addresses three topics: why the Sprint is valuable (Sprint Goal), what can be Done (backlog items), and how the work will get done (plan).

The Daily Scrum is a 15-minute event for Developers to inspect progress toward the Sprint Goal and adapt the Sprint Backlog; it is not a status meeting for the Product Owner.

The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product; if not defined by the organization, the Scrum Team creates it.

Sprint length is fixed once chosen; a Sprint may be cancelled only by the Product Owner, and only if the Sprint Goal becomes obsolete.

The Product Owner is accountable for maximizing product value, and does so by managing the Product Backlog effectively; the role is one person, not a committee.

Three Product Owner accountabilities per the Scrum Guide: developing and communicating the Product Goal, creating and ordering Product Backlog items, and ensuring the backlog is transparent, visible, and understood.

Product Goal is a long-term objective for the Scrum Team, lives in the Product Backlog, and is the target the team plans against; only one Product Goal is active at a time.

Backlog ordering criteria include value, risk, dependencies, size, and learning; the Product Owner orders items and may delegate the work but not the accountability.

Sprint Goal is a single objective for the Sprint, created collaboratively during Sprint Planning and committed to by the Developers; it can be met by delivering one or more Increments.

The Product Owner may represent stakeholder needs in the Product Backlog; stakeholders should be engaged continuously, and the Sprint Review is the formal inspect-and-adapt point with them.

Agile principles from the Agile Manifesto prioritize individuals and interactions, working software, customer collaboration, and responding to change over their counterparts.

An Increment is a concrete stepping stone toward the Product Goal; each Increment is additive to prior Increments and must be usable, so value can be delivered before the Sprint ends.

Value is measured by outcomes, not output volume; Product Owners use evidence such as usage data, feedback, and business metrics to reorder the backlog.

Product vision describes the future state the product creates for customers; it is broader and longer-lived than the Product Goal, which is a measurable step toward that vision.

A useful vision statement names the customer, the need, the product, and the differentiating value; it guides backlog ordering when trade-offs are ambiguous.

Backlog refinement is an ongoing activity of adding detail, estimates, and order to items; it is not a formal Scrum event, and the Scrum Team decides how and when to do it.

User stories commonly follow the form: As a , I want , so that ; acceptance criteria define when a story satisfies the Definition of Done.

Story splitting techniques include workflow steps, business rule variations, data entry variations, and simple/complex paths; each slice should deliver value or learning.

Stakeholder mapping identifies influence and interest; high-influence, high-interest stakeholders need frequent engagement, while low-influence, low-interest groups need monitoring.

Sprint Review is a working session, not a presentation; attendees collaborate on what was done, what changed, and what to do next, and the Product Backlog may be adjusted.

Forecast vs. commitment: the Developers forecast what they can deliver; scope may be renegotiated with the Product Owner as learning occurs, while the Sprint Goal is protected.

A Product Owner facing conflicting stakeholder demands makes trade-offs visible in the ordered backlog and uses the Sprint Review and Product Goal to align expectations.

The Scrum Master is accountable for the Scrum Team's effectiveness, coaching the team and the organization in empiricism; the role is a true leadership role, not a project manager or secretary.

Developers are the people in the Scrum Team committed to creating any aspect of a usable Increment each Sprint; they self-manage and decide how to turn backlog items into value.

Sprint Retrospective concludes the Sprint; its purpose is to plan ways to increase quality and effectiveness, and it produces actionable improvements, some of which may enter the next Sprint Backlog.

The Sprint Backlog is composed of the Sprint Goal, the selected backlog items, and the plan for delivering them; it is a highly visible real-time picture of the Developers' work.

Scrum is founded on empiricism and lean thinking; empiricism asserts knowledge comes from experience, and lean thinking reduces waste and focuses on essentials.

The Product Backlog is an emergent, ordered list of what is needed to improve the product; it is the single source of work undertaken by the Scrum Team.

Timeboxes: Sprint 1 month or less, Sprint Planning 8 hours max for a 1-month Sprint, Daily Scrum 15 minutes, Sprint Review 4 hours max, Retrospective 3 hours max.

Scrum is deliberately incomplete; it defines only the parts required to implement its theory, and teams add practices and techniques within the framework.

The Sprint is the heart of Scrum: it is a fixed-length event in which ideas turn into value, and no changes are made that would endanger the Sprint Goal.

Definition of Ready is not part of Scrum; if a team uses one, it is a local agreement and must not become a gate that blocks backlog transparency or the Product Owner's ordering.

Product Owner decisions should be transparent; the backlog order is the primary communication tool for what the team will do next and why.

Customer collaboration over contract negotiation means the Product Owner works with stakeholders to discover needs iteratively rather than specifying everything up front.

Responding to change over following a plan means the Product Backlog is reordered as new information arrives; the Sprint Goal provides short-term stability while the backlog stays flexible.

Working software over comprehensive documentation means the Increment is the primary measure of progress; documentation should add value, not substitute for a usable product.

Prioritization frameworks such as MoSCoW, cost of delay, or weighted shortest job first can inform ordering; the Product Owner remains accountable for the final order.

The Product Owner is accountable for the Product Backlog's transparency; if items are unclear or unordered, the team cannot inspect and adapt effectively.

Stakeholder feedback loops include Sprint Review, user research, analytics, and direct conversations; the Product Owner synthesizes these inputs into backlog decisions.

A Product Owner who cannot make a decision should surface the trade-off and the missing information, rather than defaulting to the loudest stakeholder or the highest-paid person's opinion.

Scrum's three pillars are supported by the five values: commitment, focus, openness, respect, and courage; the values guide behavior within the framework.

The Product Owner, Scrum Master, and Developers are the three accountabilities; the Scrum Guide uses 'accountabilities' rather than 'roles' to emphasize ownership of outcomes.

The Sprint Review inspects the outcome of the Sprint and determines future adaptations; the Product Backlog may be adjusted, and the Increment is presented to stakeholders.

The Daily Scrum is held at the same time and place every working day to reduce complexity; if the Product Owner or Scrum Master participates, they do so as Developers.

The Definition of Done creates transparency by providing a shared understanding of what work was completed as part of the Increment.

Scrum events are opportunities to inspect and adapt; failing to hold them, or using them for other purposes, breaks the empirical process.

The Increment is the sum of all completed backlog items during a Sprint plus the value of prior Increments; it must meet the Definition of Done to be considered complete.

The Product Backlog commitment is the Product Goal; the Sprint Backlog commitment is the Sprint Goal; the Increment commitment is the Definition of Done.

Scrum is a framework for complex product delivery; it is not a methodology, process, or technique, and it does not prescribe engineering practices.

Backlog items are ordered by value, risk, and dependency; the Product Owner may use estimates from Developers but owns the ordering decision.

The Product Owner should ensure the backlog is visible and understood; unclear items are refined before they reach the top of the order, not after the Sprint starts.

A Sprint Goal gives the Developers flexibility on scope; if the work turns out different than expected, they negotiate scope with the Product Owner rather than abandoning the goal.

Value can be delivered incrementally; the Product Owner encourages releasing increments when they are usable, rather than waiting for a single large release.

Stakeholder collaboration is continuous; the Sprint Review is the formal event, but the Product Owner also engages stakeholders between Sprints to reduce surprises.

Product vision and Product Goal must be communicated so the team can make trade-offs; a team without a goal optimizes locally and delivers less value.

The Product Owner is one person; if the work is too large, the Product Owner may delegate tasks but remains accountable for the backlog and value.

Evidence-based ordering uses data such as usage, revenue, retention, and support load; opinions are inputs, but outcomes are the measure of value.

A Product Owner should say no by reordering, not by refusing to listen; every request is a candidate for the backlog, and the order shows priority.

Sprint Planning is timeboxed to a maximum of 8 hours for a 1-month Sprint; for shorter Sprints, the event is usually shorter.

The Sprint Review is timeboxed to a maximum of 4 hours for a 1-month Sprint; it is a working session with stakeholders, not a demo-only meeting.

The Sprint Retrospective is timeboxed to a maximum of 3 hours for a 1-month Sprint; it concludes the Sprint and precedes the next Sprint Planning.

The Daily Scrum is a 15-minute event for the Developers; it can be held at any time and place as long as it is consistent, and it is not a status report to management.

Sprint Planning answers why (Sprint Goal), what (items selected), and how (plan); the Sprint Backlog is created or updated during this event.

The Sprint is a container for all other events; it is fixed in length, and a new Sprint starts immediately after the previous one ends.

The Sprint Review inspects the Increment and adapts the Product Backlog; the Retrospective inspects the team's process and adapts the way of working.

No Scrum event is optional; skipping an event removes an inspection-and-adaptation opportunity and undermines transparency.

The Product Owner may cancel a Sprint if the Sprint Goal becomes obsolete; cancellation is rare and consumes resources, so it is a last resort.