PSD cheat sheet

Scrum is a lightweight framework built on empiricism: decisions rest on observation, experience, and experimentation; the three pillars are transparency, inspection, and adaptation.

Five Scrum events exist: the Sprint (a container of 1 month or less), Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective; no other meetings are prescribed.

Three accountabilities: Product Owner (maximizes product value), Scrum Master (establishes Scrum per the Scrum Guide), Developers (build the Increment).

Three artifacts: Product Backlog (Product Owner accountable), Sprint Backlog (Developers accountable), Increment (Developers accountable); each has a commitment - Product Goal, Sprint Goal, Definition of Done.

The Sprint is a fixed-length container of 1 month or less; only the Product Owner may cancel it, and cancellation happens when the Sprint Goal becomes obsolete.

Scrum values are commitment, focus, openness, respect, and courage; they are not aspirational slogans but criteria for evaluating team behavior.

The Sprint Goal is a single objective for the Sprint created during Sprint Planning; it is the only item in the Sprint Backlog that cannot be changed mid-Sprint without renegotiation.

Empirical process control applies where work is complex; if the work were predictable, a defined process would suffice and Scrum's inspect-and-adapt loop would add no value.

Definition of Done is a formal description of the Increment's quality state; if an artifact does not meet it, it cannot be released and returns to the Product Backlog.

A strong Definition of Done typically includes: code reviewed, automated tests passing, integrated into the mainline, documentation updated, and deployable to production.

Continuous Integration means every change is merged and built frequently; it keeps the Increment in a releasable state and makes the Daily Scrum's transparency real rather than reported.

Test-Driven Development cycle: write a failing test (red), write the minimum code to pass (green), refactor while keeping tests green.

Refactoring changes internal structure without changing observable behavior; it is the practice that keeps a codebase able to absorb Sprint-level change.

Trunk-based development with short-lived branches (hours to a day) reduces merge risk; long-lived feature branches hide integration problems until late in the Sprint.

Automated regression tests are the safety net for refactoring and continuous integration; manual-only testing cannot keep pace with daily integration.

Technical debt is a trade-off, not a failure; it must be made visible in the Product Backlog and negotiated with the Product Owner rather than silently absorbed.

Developers are the people in the Scrum Team committed to creating any aspect of a usable Increment each Sprint; the Scrum Guide no longer uses the title 'Development Team'.

Developers are self-managing: they decide internally who does what, when, and how; the Scrum Master does not assign tasks and the Product Owner does not direct the how.

Cross-functional means the team collectively holds all skills needed to produce a Done Increment each Sprint, not that every member has every skill.

Developers own the Sprint Backlog, the Definition of Done (with the organization's standards as a floor), and the technical quality of the Increment.

The Scrum Team is one team of ten or fewer people total; if it grows larger, split into multiple cohesive Scrum Teams sharing one Product Goal and one Product Backlog.

Developers adapt their plan daily at the Daily Scrum; the event is for inspection toward the Sprint Goal, not a status report to a manager.

The Product Owner may attend the Daily Scrum but does not facilitate or direct it; the Developers choose the structure and the Scrum Master ensures the event happens and stays within 15 minutes.

Collective ownership: no single person is the sole gatekeeper of a code area; knowledge silos violate the cross-functional, self-managing premise.

The Increment is the sum of all completed, usable work in a Sprint plus the value of prior Increments; it must be usable, so it must meet the Definition of Done.

An Increment is delivered as soon as it is Done, not held to the end of the Sprint; multiple Increments may be produced within one Sprint.

'Potentially releasable' means the Product Owner could choose to release it now; it does not mean it must be released.

The Definition of Done is the gate: work that is not Done is not part of the Increment and returns to the Product Backlog for re-estimation.

The Sprint Review inspects the Increment and adapts the Product Backlog; it is a working session, not a demo-only ceremony, and its outcome is a revised backlog.

Vertical slicing (thin end-to-end functionality) produces releasable value each Sprint; horizontal slicing (a layer at a time) cannot produce a usable Increment.

Release frequency is a Product Owner decision; the Developers' obligation is to keep every Increment in a state where release is possible on demand.

Forecasting uses the Sprint Backlog and past performance; velocity is a planning aid, not a target, and never a performance measure imposed on the team.