Scrum Artefacts and Events: Commitments, Timeboxes and Purpose
This domain tests precise knowledge of the three artefacts, the three commitments attached to them, and the five events - what each is for, who attends, and how long it may run. Vague answers such as "the review is where we demo" cost marks because they miss the inspection-and-adaptation purpose.
Artefacts and their commitments
The Product Backlog is an emergent, ordered list of what is needed to improve the product; the Product Owner orders it and the Product Goal gives it focus. The Sprint Backlog is composed of the Sprint Goal (why), the selected items (what) and the plan to deliver them (how); it belongs to the Developers and is updated throughout the Sprint. The Increment is the concrete, usable step toward the Product Goal, and work does not count as part of it unless it meets the Definition of Done.
The events
The Sprint is the container for the other four and is fixed at one month or less. Sprint Planning (max 8 hours for a one-month Sprint) answers why, what and how, and produces the Sprint Goal and Sprint Backlog. The Daily Scrum is a 15-minute event for the Developers to inspect progress toward the Sprint Goal and adapt the Sprint Backlog - not a status report to the Scrum Master. The Sprint Review (max 4 hours) inspects the outcome with stakeholders and adapts the Product Backlog; it is a working session, not a sign-off gate. The Sprint Retrospective (max 3 hours) inspects individuals, interactions, processes, tools and the Definition of Done, and produces improvements.
Worked example
A team's Daily Scrum runs 25 minutes, with each developer reporting to the Scrum Master in turn. Diagnosis: the event has become a status meeting serving the wrong people. Fix: the Developers run it themselves, organise it around the Sprint Goal and walk the board; the Scrum Master attends to observe and coach. Note that shortening the event is not the goal - 15 minutes is a timebox, not a target, and enforcing the box is part of the Scrum Master's accountability.
Traps
- Turning the Sprint Review into a demo with no stakeholder feedback and no backlog adaptation.
- Cancelling a Sprint for any reason other than the Sprint Goal becoming obsolete - and only the Product Owner may cancel.
- Inventing "Sprint 0", a "hardening Sprint", or mid-Sprint scope changes forced on the Developers.
- Running a Retrospective with no owned actions, or treating the Daily Scrum as the only moment to adapt.