Scrum's cadence is the most visible part of the framework. Five events — one big container and four inside it — give the team rhythm, focus, and regular checkpoints to inspect and adapt.
The Sprint
The Sprint is a fixed-length container, typically two weeks (one to four is allowed). All other events happen within it. Each Sprint produces a usable, valuable Increment.
- Fixed length. Same duration every time. Predictable cadence.
- No interruptions to the Sprint Goal. Once committed, the team protects the goal.
- Cancellable only by the Product Owner if the Sprint Goal becomes obsolete. Rare.
Why fixed-length? Because variable-length sprints break the rhythm that lets the team learn its own velocity and quality.
Sprint Planning
Maximum 8 hours for a one-month Sprint; proportionally less for shorter Sprints (typically 2 hours per week of Sprint).
Three topics:
- Why is this Sprint valuable? The Product Owner proposes objectives; the team converges on a Sprint Goal — a single concise statement of what the Sprint should accomplish.
- What can be done this Sprint? The team selects backlog items it believes it can complete given the goal, capacity, and Definition of Done.
- How will the chosen work get done? The Developers decompose items into a workable plan — the initial Sprint Backlog.
The output is the Sprint Goal and the Sprint Backlog.
The Daily Scrum
15 minutes, every working day, same time and place, attended by the Developers. The Product Owner and Scrum Master may attend if they are also working as Developers, but the meeting belongs to Developers.
Purpose: inspect progress toward the Sprint Goal and adapt the plan for the next 24 hours. Not a status meeting; not for management.
Common formats
- The three questions (legacy): What did I do, what will I do, what blocks me? Often becomes a status round-robin.
- Walk the board. Start from the right (closest to done); discuss each item that needs attention.
- Focus on the goal. "What's our biggest risk to the Sprint Goal?" Drives meaningful conversation.
The format is the team's choice. The 15-minute timebox is not.
Sprint Review
Maximum 4 hours for a one-month Sprint; proportionally less.
The team and stakeholders inspect the Increment together. Topics:
- Demo what was built — actual working software.
- Discuss what is done, what isn't, what we learned.
- Adapt the Product Backlog based on feedback.
- Forecast the next Sprint and beyond.
This is not a sign-off ceremony. It is a working session. Stakeholders should leave influencing future direction; the Product Owner decides.
Sprint Retrospective
Maximum 3 hours for a one-month Sprint; proportionally less.
The Scrum Team inspects itself. Topics:
- How did the Sprint go in terms of individuals, interactions, processes, tools, and Definition of Done?
- What went well, what didn't?
- What will we change next Sprint?
The output is at least one concrete improvement that the team commits to in the next Sprint.
Format ideas
- Start / Stop / Continue. Simple and quick.
- 4 Ls — Liked, Learned, Lacked, Longed for.
- Sailboat — what propels us, what anchors us, what we head toward.
- Mad / Sad / Glad — emotional read on the Sprint.
Vary formats so the retro doesn't become routine.
Anti-patterns
- No follow-through. Same issues raised every Sprint; no improvement adopted.
- Blame culture. Retros that surface "who" instead of "what."
- Skipping when busy. The retro is the most important meeting; skipping it is the surest sign of trouble.
Backlog Refinement (Not an Event)
The Scrum Guide does not list refinement as a formal event, but most teams set aside time mid-Sprint to refine upcoming items: clarify, split, estimate. Aim to keep enough refined items "ready" for at least the next Sprint.
If your Sprint Planning is constantly painful, refinement is too thin.
Time Boxes Summary
| Event | Max for 1-month Sprint | Typical for 2-week Sprint |
|---|---|---|
| Sprint Planning | 8 hours | 4 hours |
| Daily Scrum | 15 minutes | 15 minutes |
| Sprint Review | 4 hours | 2 hours |
| Sprint Retrospective | 3 hours | 1.5 hours |
Why Time Boxes Matter
The boxes prevent meetings from sprawling. They force preparation. And they create a repeatable cadence — predictability the team can plan around. A team that ignores time boxes ends up either in endless meetings or skipping events entirely.
Cert Mapping
| Cert | Scope |
|---|---|
| PSM I | Events and time boxes are heavily tested |
| PMI-ACP | Events plus other Agile ceremonies |
| SAFe Agilist | Scrum events plus PI Planning and System Demo |
The next lesson covers the artifacts the events produce and inspect.