Scrum Theory and Framework Applied to Software Development
What this domain tests
The PSD exam does not ask you to recite the Scrum Guide; it asks whether you can apply empiricism and the framework's rules to real software work - code, builds, tests, and dependencies.
Empiricism made visible in software
Transparency requires that everyone can see the true state of the work: a refined Product Backlog, a Sprint Backlog that reflects the plan, and working software that meets the Definition of Done. Inspection happens in every event - the Sprint Review inspects the Increment with stakeholders, the Daily Scrum inspects progress toward the Sprint Goal, the Retrospective inspects how the team works. Adaptation is the response: re-plan the Sprint Backlog, reorder the Product Backlog, change a practice. Faked transparency - "done" meaning merged but untested - poisons both inspection and adaptation.
The non-negotiable framework rules
- Three accountabilities: Product Owner (product value), Scrum Master (team effectiveness), Developers (creating the Increment).
- Five events, each timeboxed, with the Sprint as container: Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective.
- Three artifacts, each with a commitment: Product Backlog → Product Goal; Sprint Backlog → Sprint Goal; Increment → Definition of Done.
- Five values: commitment, focus, openness, respect, courage.
Worked example
Mid-Sprint, a team discovers an external API is delayed and the Sprint Goal is at risk. The framework's answer: Developers re-plan the Sprint Backlog daily and negotiate scope with the Product Owner, who is the only person who can cancel the Sprint. If remaining work can still satisfy the Sprint Goal, the Sprint continues with adjusted scope. What is not valid is quietly lowering the Definition of Done so unfinished items "count" - that is a transparency failure, not adaptation.
Traps that cost marks
Treating the Sprint Review as an approval gate; using the Daily Scrum to report status to the Scrum Master; inventing "Sprint 0" or a "hardening Sprint"; believing refinement is a formal event (it is an ongoing activity); assuming the Developers alone can cancel a Sprint.