Events, Artifacts and Commitments

Every Scrum event has a corrupted twin. The planning session that's really a negotiation. The daily sync that's really a status report. The review that's really a rehearsed demo. The retrospective that's really… cancelled. Same names, same calendar slots, opposite purposes. By the end of this lesson you'll know each event's real reason for existing — which means you'll recognize the twin the moment you meet it.

By the end of this video, you'll be able to describe Scrum's five events by their purpose, its three artifacts with the commitment each one carries, and define the term this entire course keeps leaning on: the Definition of Done.

Event one is the strange one, because it isn't a meeting: the Sprint itself. A fixed-length cycle, one month or less — commonly two weeks — that contains everything else. Two properties give it its power. It's fixed: the length never stretches to fit unfinished work; the heartbeat stays steady and the work adapts to it, not the reverse. And it's a container: every other event happens inside it, once per cycle, which is why teams stop debating whether to plan or reflect — the rhythm decides, so the team doesn't have to renegotiate its own discipline every week. That's the loop from Lesson 1, given a pulse.

Sprint Planning opens each Sprint. Purpose: leave the room with a shared answer to three questions — why is this Sprint worth running (that answer gets a name in a moment), what will we pull from the backlog, and how do we intend to get it done. Planning is the team deciding its own bet for the cycle — which is exactly why its corrupted twin, a session where scope is imposed on the team, isn't planning at all. It's dictation with sticky notes.

The Daily Scrum: fifteen minutes, every day, Developers only in the driver's seat. Purpose: the team inspects its progress toward the Sprint's goal and adjusts today's plan. It is the team's own navigation huddle — the empiricism engine running at its fastest cadence. What it is not: a status report. The moment a manager stands at the front collecting updates and assigning tasks, three things die quietly: self-management, honesty, and usually the fifteen-minute limit. Same room, same time, opposite event.

Sprint Review, at the Sprint's end. Purpose: show the real Increment to real stakeholders and adapt the backlog based on what everyone learns. The operative word is working session — stakeholders touch the thing, react to the thing, and their reactions reshape what comes next. The corrupted twin is demo-theater: a rehearsed performance, applause, no backlog changes. If the backlog looks identical after the Review, no review occurred — a presentation did.

Sprint Retrospective, the final event of each Sprint. Purpose: the team inspects not the product but itself — how the work worked — and picks an improvement. That's all I'll say, deliberately: this event is so important it gets its own full lesson in Module 4. For now, its position matters: last, so each Sprint closes by making the next one slightly better.

One honorable mention that is not an event: backlog refinement — the ongoing activity of clarifying and re-slicing upcoming items so Planning isn't archaeology. It happens continuously, sized to need, not boxed to a ceremony.

Scrum has exactly three artifacts, and here's the elegant part almost every beginner course skips: each artifact carries a commitment — a promise that gives it direction.

The Product Backlog you know: the single, ordered, living list. Its commitment is the Product Goal — the longer-term destination the whole list is marching toward. Without it, a backlog is just a well-ordered pile.

The Sprint Backlog is the Sprint's plan: the items pulled for this cycle plus the team's approach for delivering them — owned by the Developers, adjustable by the Developers as the Sprint teaches them things. Its commitment is the Sprint Goal: the single sentence that says why this Sprint matters. The Goal is what makes a Sprint coherent instead of a fortnight of unrelated tasks — and it's the "why" that Planning exists to produce.

The Increment: the concrete, usable slice of product the Sprint produces. Its commitment is the one this course will not stop using: the Definition of Done.

The Definition of Done is the team's shared, written quality bar — the checklist every single item must pass before anyone may call it done. A bakery team's might read: works on phones, live on the real site, staff briefed. Notice three properties. It's shared: one bar for everyone, so "done" means the same thing in every mouth. It's explicit: written down, not assumed — assumptions are where done-faking breeds. And it applies to every item, always, until the team deliberately raises the bar.

Here is the sentence to carry out of this module: done means usable, not "I finished my part." A thing that's coded but untested, drafted but unpublished, built but unusable — is not done; it's inventory wearing a medal. Module 3 will sharpen this idea into something even stronger, but the foundation is poured right here.

You might think these four meetings sound like a lot of process for people who claim to travel light. That's understandable — four recurring meetings on a calendar looks heavy. Actually, count what the events replace: the status meetings, steering committees, launch reviews, escalation calls, and re-planning summits that unstructured work breeds like mold. Scrum's events are a fixed, minimal price — roughly a tenth of a two-week Sprint — paid to make every other meeting unnecessary. The teams drowning in meetings are almost never the ones running honest Scrum events. They're the ones running the corrupted twins plus everything else.

Three things to keep. One: the Sprint is the container — fixed length, steady heartbeat — holding Planning, Daily Scrum, Review, and Retrospective, each defined by purpose, each with a corrupted twin you can now spot. Two: three artifacts, three commitments — Backlog with its Product Goal, Sprint Backlog with its Sprint Goal, Increment with its Definition of Done. Three: done means usable — a shared, written bar, applied to everything.

Scrum creates order through time — the boxed rhythm you've just learned. But there's a second, entirely different way to create order: leave time unboxed and put limits on the work instead. It has six practices, a Japanese name, and it's next.