Scrum & Agile — Intermediate

Scrum's five events

Applying Fundamentals' empiricism pillars to Scrum's concrete structure: the Sprint is the container event — a fixed-length iteration (typically 1-4 weeks) during which a usable, potentially releasable product increment is created, with all other events occurring within it. Within each Sprint: Sprint Planning (the team plans the work to be performed during the Sprint, establishing the Sprint Goal — enabling transparency about what's planned), the Daily Scrum (a short, daily event for the Developers to inspect progress toward the Sprint Goal and adapt the plan for the next day — directly enabling inspection and adaptation), the Sprint Review (held at the Sprint's end to inspect the outcome and adapt the Product Backlog if needed, typically involving stakeholders reviewing the increment), and the Sprint Retrospective (held after the Sprint Review and before the next Sprint Planning, where the team inspects how the last Sprint went regarding people, relationships, process, and tools, then plans improvements — directly connecting to the Agile Manifesto principle about regularly reflecting and adjusting, Fundamentals).

Scrum's three artifacts

Scrum defines three artifacts, each representing work or value, with each carrying a specific commitment ensuring transparency and focus: the Product Backlog (an ordered, emergent list of everything needed to improve the product, owned by the Product Owner), with its commitment being the Product Goal (the long-term objective the Scrum Team works toward); the Sprint Backlog (the Sprint Goal, plus the set of Product Backlog items selected for the Sprint, plus the Developers' plan for delivering the increment), with its commitment being the Sprint Goal itself; and the Increment (a concrete stepping stone toward the Product Goal, meeting the Scrum Team's Definition of Done), with its commitment being the Definition of Done (the formal description of the state the Increment must be in to be considered complete). This artifact-commitment pairing is a frequently tested structural detail — each artifact has exactly one associated commitment, not an arbitrary or interchangeable set.

Daily Scrum — what it is and isn't

A commonly tested misconception: the Daily Scrum is not a status-update meeting for the Scrum Master or a reporting session to management — it's a Developer-focused planning and inspection event, where the Developers themselves inspect progress toward the Sprint Goal and adapt the Sprint Backlog as needed, adjusting the upcoming work. The Scrum Master ensures the event happens and stays within its timebox (typically 15 minutes) but doesn't run it as a status-reporting session directed at them — this distinction connects back to Fundamentals' point about the Scrum Master's facilitative, not directive, role.

The Definition of Done — why it matters structurally

Building on the Increment/Definition-of-Done pairing above: the Definition of Done exists to create a shared, objective understanding of what "complete" means for any Increment — without it, different team members (or the Product Owner and Developers) could have different, unstated assumptions about whether work is genuinely finished, undermining the transparency pillar (Fundamentals) that Scrum's empirical process depends on. A Product Backlog item that doesn't meet the Definition of Done cannot be considered part of the Increment or released, regardless of how much work went into it — this is a hard structural rule, not a flexible guideline.

Connecting events and artifacts to empiricism's three pillars

The intermediate-level synthesis: each Scrum event and artifact maps back to Fundamentals' empiricism pillars in a specific, learnable way — Sprint Planning and the Sprint Backlog primarily serve transparency (making the plan visible), the Daily Scrum primarily serves inspection and adaptation (checking progress and adjusting), and the Sprint Review/Retrospective primarily serve inspection (of the product and process respectively) leading to adaptation. Recognizing this mapping — rather than memorizing five events and three artifacts as an arbitrary list — is what makes Scrum's structure feel like a coherent, purpose-built system.