Scrum Events Explained: What They Are, Why They Exist, and How to Use Them

The Scrum events are one of the highest-yield topics for the PSM I exam — and one of the most misunderstood in practice. The Scrum Guide 2020 defines five events. Each is a formal opportunity to inspect and adapt. None of them exist to provide status updates. Understanding that distinction is the foundation of everything else.

The Purpose of Scrum Events

Scrum is built on empiricism: the idea that knowledge comes from experience and decisions should be based on what is actually observed. The five events create the structure for that empiricism to operate. They are not ceremonies. They are not bureaucratic overhead. They are the mechanism by which a Scrum Team regularly examines what is happening and adjusts accordingly.

Every timebox in Scrum is a maximum, not a target. Events end when their purpose is served.

1. The Sprint

Timebox: Up to one calendar month

The Sprint is the container for all other events. Everything in Scrum happens within a Sprint. Sprints have consistent lengths throughout the product development effort — changing the length constantly undermines predictability and learning.

Key rules from the Scrum Guide 2020:

• No changes are made that would endanger the Sprint Goal
• Quality does not decrease
• The Product Backlog is refined as needed
• Scope may be clarified and renegotiated with the Product Owner as more is learned

Only the Product Owner can cancel a Sprint, and only if the Sprint Goal becomes obsolete. Sprint cancellations are rare and disruptive.

What goes wrong in practice: Teams treat the Sprint length as flexible — extending it when work is incomplete or shortening it when things go well. This destroys the rhythm that makes Sprint Reviews and Retrospectives meaningful.

2. Sprint Planning

Timebox: 8 hours for a one-month Sprint (proportionally shorter for shorter Sprints)

Who attends: The entire Scrum Team (Scrum Master, Product Owner, Developers)

Sprint Planning addresses three topics:

1. Why is this Sprint valuable? — The Scrum Team collaborates to define a Sprint Goal
2. What can be Done this Sprint? — Developers select items from the Product Backlog
3. How will the chosen work get done? — Developers decompose selected items into a plan

Outputs: The Sprint Goal (the commitment for the Sprint) and the Sprint Backlog (the Sprint Goal, selected Product Backlog items, and the plan for delivering the Increment).

The Sprint Goal is created during Sprint Planning by the entire Scrum Team — this is a common exam question. It is not created by the Product Owner alone.

What goes wrong in practice: Sprint Planning becomes a task assignment meeting where the Scrum Master or manager distributes work. Developers should pull their own work and own the plan.

3. Daily Scrum

Timebox: 15 minutes

Who attends: The Developers — this is the Scrum Guide's term for the development team members. The Scrum Master and Product Owner are not required attendees, though they may be present.

The purpose of the Daily Scrum is for the Developers to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary. The Developers choose whatever structure works for them — the three questions format is not mandated by the Scrum Guide 2020.

What goes wrong in practice: The Daily Scrum becomes a status report to the Scrum Master or manager. Each developer recites what they did yesterday and what they will do today, with no discussion of impediments or Sprint Goal progress. This turns a coordination event into a reporting ceremony.

4. Sprint Review

Timebox: 4 hours for a one-month Sprint

Who attends: The Scrum Team and stakeholders (invited by the Product Owner)

The Sprint Review is the second-to-last event of the Sprint. Its purpose is to inspect the Increment produced during the Sprint and adapt the Product Backlog based on what was learned. The Scrum Team and stakeholders discuss what was accomplished, what changed in the environment, and what to focus on next.

The Sprint Review is not a demo. It is a collaborative working session. Stakeholders do not passively watch a presentation — they engage with the product and contribute to Product Backlog decisions.

The output of the Sprint Review is a revised Product Backlog.

What goes wrong in practice: Teams treat the Sprint Review as a sign-off gate. Stakeholders approve or reject work, and the team either celebrates or defends itself. This is the opposite of the collaborative inspection-and-adapt session the Scrum Guide describes.

5. Sprint Retrospective

Timebox: 3 hours for a one-month Sprint

Who attends: The Scrum Team only — no external stakeholders

The Sprint Retrospective is the last event of the Sprint. Its purpose is for the Scrum Team to inspect itself — how individuals interact, processes, tools, and the Definition of Done — and to identify improvements to enact in the next Sprint.

The most actionable improvements should be added to the next Sprint Backlog. This is a specific Scrum Guide point that exam questions test: improvements are not vague commitments, they are concrete actions placed into the backlog.

What goes wrong in practice: Retrospectives become complaint sessions with no follow-through. Teams identify the same problems Sprint after Sprint without committing to specific, trackable improvements. A Retrospective without an action added to the Sprint Backlog is an inspection without adaptation — which defeats its purpose.

The Pattern That Connects All Five Events

Every Scrum event follows the same logic: inspect something, then adapt something.

Event	Inspect	Adapt
Sprint	Sprint Goal progress (ongoing)	Sprint Backlog
Sprint Planning	Product Backlog	Sprint Backlog + Sprint Goal
Daily Scrum	Progress toward Sprint Goal	Sprint Backlog
Sprint Review	Increment	Product Backlog
Sprint Retrospective	Team, process, tools	Next Sprint Backlog (improvements)

For PSM I candidates, understanding this inspect-and-adapt logic is more valuable than memorising timeboxes. When an exam question describes a team skipping an event or misusing it, the correct answer will almost always involve restoring the event's inspect-and-adapt purpose.

Mastering the Scrum events means understanding not just what each one is, but why the Scrum Guide 2020 defines it the way it does.