# Events, Artifacts and Commitments

Explain the purpose of Scrum's events and pair each artifact with the commitment that gives it meaning.

Duration: 12 min

The Sprint is a fixed-length container for planning, daily inspection, stakeholder review, and team reflection. Each event exists to create a decision or adaptation, not to satisfy a calendar ritual.

Three pairs keep the work coherent: Product Backlog and Product Goal, Sprint Backlog and Sprint Goal, and Increment and Definition of Done. Done means usable, not merely that one person's part has stopped.

## fmap-m2-l3-v1

The animation draft is not an approved provider asset. Keep this record in review with the explicit pending ID until final media and human-reviewed captions exist. The digest is the equivalent text path.

## fmap-m2-l3-digest

### The rhythm: five events, three artifacts, three commitments

The **Sprint** is a fixed-length cycle of one month or less that contains every other Scrum event. Its length does not stretch to fit unfinished work; the steady rhythm remains and the work adapts.

- **Sprint Planning** establishes why the Sprint matters, what may be included, and how Developers expect to approach it. Its corrupted twin is scope imposed on the team.
- **Daily Scrum** gives Developers 15 minutes to inspect progress toward the Sprint Goal and adjust today's plan. Its corrupted twin is a status report to a manager.
- **Sprint Review** lets stakeholders inspect the real Increment and adapt the Product Backlog. A rehearsed demonstration that changes nothing is review theater.
- **Sprint Retrospective** lets the team inspect and improve its way of working. Cancelling it whenever work feels busy removes the improvement engine.

Backlog refinement is useful but is not a formal Scrum event. It is ongoing clarification and re-slicing so Planning does not become archaeology.

Each artifact has a commitment:

- **Product Backlog → Product Goal:** an ordered list connected to a longer-term destination.
- **Sprint Backlog → Sprint Goal:** the Developers' plan for this cycle, held together by one reason the Sprint matters.
- **Increment → Definition of Done:** a usable result that passes the team's shared quality bar.

The Definition of Done is shared, explicit, and applied to every item. “Done” means usable, not “I finished my part.” Unusable work remains inventory regardless of how many local tasks have stopped.

The recurring events may look heavy until compared with the status meetings, steering meetings, and escalations they are intended to replace. Purpose comes before mechanics: every event should generate truthful inspection or a useful adaptation.

## fmap-m2-l3-r1

### A two-week Sprint on one page

**Team:** six volunteers organizing a neighborhood festival  
**Sprint Goal:** Vendors confirmed and the family zone fully planned.

| Day       | Week 1                                                         | Week 2                                                                                  |
| --------- | -------------------------------------------------------------- | --------------------------------------------------------------------------------------- |
| Monday    | Sprint Planning: agree why, what, and how; set the Sprint Goal | Daily Scrum, 15 minutes                                                                 |
| Tuesday   | Daily Scrum, 15 minutes                                        | Daily Scrum, 15 minutes                                                                 |
| Wednesday | Daily Scrum; refine candidates for the next Sprint             | Daily Scrum; brief refinement as needed                                                 |
| Thursday  | Daily Scrum, 15 minutes                                        | Daily Scrum, 15 minutes                                                                 |
| Friday    | Daily Scrum, 15 minutes                                        | Sprint Review with sponsors and community representatives; then team-only Retrospective |

The Daily Scrum is the team's navigation huddle, not a report upward. The Review should end with learning reflected in the Product Backlog. The Retrospective should end with a small, owned experiment for the next cycle.

This is an example rhythm, not a mandatory meeting template. Adapt durations to the team and work while preserving each event's purpose.