The 5 Scrum Events: A Complete Guide for PSM I & CSM Exams (2026)

If you've been studying for the PSM I or CSM exam, you've probably noticed that the five Scrum events show up everywhere — in scenario questions, tricky edge cases, and those deceptively simple "who attends this event?" traps. And for good reason. The events aren't just calendar items. They're the heartbeat of empiricism in Scrum, giving the team structured opportunities to inspect and adapt at every level of the work.

The 2020 Scrum Guide made some meaningful changes to how these events are framed — particularly around accountability and the Sprint Goal — and those updates are absolutely fair game on both the PSM I and CSM exams. If you're still studying from older material or relying on a summary that predates 2020, you may be walking into the exam with outdated information. This guide fixes that.

What you'll find here is a thorough, exam-ready breakdown of all five Scrum events: their purpose, their timeboxes, who's involved, and the common misconceptions that cost candidates points. Think of this as the conversation you'd have with a seasoned Scrum coach the week before your exam — honest, specific, and built around what actually matters.

---

The Sprint: The Heartbeat of Scrum and Its Container

Before diving into the individual events, it's worth understanding what the Sprint is at a conceptual level, because this framing will help you answer some of the more nuanced exam questions.

The Sprint is the container for all other Scrum events. It's a fixed-length iteration — one month or less — during which the Scrum Team works toward a Sprint Goal and creates at least one valuable, usable Increment. Every other event — Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective — happens within the Sprint. That's not a trivial point. It means the Sprint isn't just "the time between planning and review." It's an active, living structure.

The 2020 Scrum Guide is explicit: a new Sprint begins immediately after the conclusion of the previous Sprint. There's no dead time, no "cool-down" week, no sprint zero that resets the clock. This consistency creates the cadence that makes empiricism possible.

What Can and Can't Change During a Sprint

One of the most exam-relevant aspects of the Sprint is understanding its stability rules:

• The Sprint Goal cannot be changed. If conditions change and the goal becomes obsolete, the Sprint can be cancelled — but only by the Product Owner.
• Quality does not decrease. The Definition of Done doesn't get relaxed to meet a deadline.
• Scope can be clarified and renegotiated between the Product Owner and Developers as more is learned.
• Sprints can be cancelled, but this is rare and only happens if the Sprint Goal becomes obsolete.

As a Scrum Master, one of your key responsibilities is protecting the Sprint. In practice, this means shielding the Developers from mid-Sprint scope injections, helping stakeholders understand why "just adding one small thing" undermines the team's ability to commit meaningfully. For the exam, know that the Scrum Master does this not through control or authority, but through servant leadership — coaching the team on Scrum values and facilitating conversations that preserve focus.

Sprint length is a decision made by the Scrum Team, and shorter Sprints reduce risk by creating more frequent inspect-and-adapt cycles. The exam may ask you to evaluate sprint length decisions — generally, anything over one month violates the Scrum Guide.

---

Sprint Planning: Defining the Why, What, and How

Sprint Planning kicks off every Sprint, and the 2020 Scrum Guide restructured this event around three explicit questions rather than just "what are we building?" That change is crucial for exam purposes.

Timebox: Maximum 8 hours for a one-month Sprint. Proportionally shorter for shorter Sprints (e.g., 4 hours for a two-week Sprint).

Participants: The entire Scrum Team — Product Owner, Scrum Master, and Developers. The Scrum Guide also notes that the Scrum Team may invite others to provide input.

The Three Topics of Sprint Planning

Topic 1: Why is this Sprint valuable? The Product Owner proposes how the product could increase its value and utility this Sprint. The Scrum Team then collaborates to define a Sprint Goal. This is the "why." The Sprint Goal must be finalized before Sprint Planning ends — it's not something you figure out afterward.

Topic 2: What can be Done this Sprint? The Developers select items from the Product Backlog to include in the Sprint Backlog. Crucially, only the Developers can determine how much they can take on. The Product Owner cannot assign work or override capacity judgments. This is a non-negotiable self-management principle, and you'll see it tested on the exam.

Topic 3: How will the chosen work get done? The Developers plan the work necessary to create an Increment that meets the Definition of Done. This often involves decomposing Product Backlog items into tasks of one day or less. The Scrum Master facilitates this conversation but doesn't direct the technical approach.

Exam Mindset

Watch for questions where a manager or Product Owner tries to tell the Developers what to build or how to build it during Sprint Planning. The correct Scrum response is always that Developers self-manage their work. The Product Owner owns the what (Product Backlog ordering) and the why (Sprint Goal), but the Developers own the how much and the how.

---

The Daily Scrum: Inspecting Progress Toward the Sprint Goal

The Daily Scrum is often misunderstood, both in practice and in exam questions. It's not a status meeting for the Scrum Master or management. It's a 15-minute event for and by the Developers to inspect progress toward the Sprint Goal and adapt the Sprint Backlog accordingly.

Timebox: 15 minutes, every day of the Sprint, held at the same time and place.

Participants: The Developers. The Scrum Master and Product Owner are not required to attend, though they can if they're also contributing as Developers.

What the 2020 Guide Changed Here

The old three-question format ("What did I do yesterday? What will I do today? Any impediments?") was dropped in 2020. The Scrum Guide now says Developers can use any structure or technique as long as the Daily Scrum focuses on progress toward the Sprint Goal and produces an actionable plan for the next day.

This doesn't mean the three questions are wrong — many teams still use them effectively. But for exam purposes, you should know they're not mandatory, and questions that suggest they're required are testing whether you've read the 2020 Guide.

The Scrum Master's Role in the Daily Scrum

The Scrum Master ensures the Daily Scrum happens and that Developers understand its purpose. In servant leadership terms, the Scrum Master might coach newer teams on how to make the event effective, but they don't run the meeting. If the team is mature, the Scrum Master might not even attend regularly.

A real-world scenario: imagine a Scrum Master who attends every Daily Scrum and answers questions on behalf of Developers, or who records action items and assigns them to team members. This is the opposite of what Scrum calls for. The Daily Scrum builds self-management — the Developers own the outcome of that conversation.

---

Sprint Review: Inspecting the Increment and Adapting the Backlog

The Sprint Review is frequently confused with a "demo meeting," and while a product demonstration often happens here, that framing undersells what the event is actually for.

Timebox: Maximum 4 hours for a one-month Sprint.

Participants: The Scrum Team and key stakeholders invited by the Product Owner.

What Actually Happens in a Sprint Review

The Sprint Review is an inspect-and-adapt event focused on the Increment and the Product Backlog. The Scrum Team presents their work and discusses what was done and what wasn't. Stakeholders provide feedback, and the Product Owner updates the Product Backlog based on that input and any changes to the business environment.

The 2020 Scrum Guide explicitly calls the Sprint Review a working session, not just a presentation. This distinction matters: it's collaborative, not performative. Stakeholders aren't an audience — they're participants.

What the Sprint Review Is NOT

• It is not the place where the Scrum Master evaluates team performance.
• It is not where Done/Not Done decisions are made by stakeholders. If something doesn't meet the Definition of Done, it shouldn't be presented as a completed Increment.
• It is not the Sprint Retrospective. Process improvements don't happen here.

Exam Mindset

If an exam question describes the Product Owner accepting or rejecting work during the Sprint Review, be cautious. The Product Owner has ongoing influence over the Product Backlog and what gets built, but the Sprint Review is primarily about inspecting the Increment and gathering stakeholder input — not a formal gate review.

---

Sprint Retrospective: Planning for Quality and Effectiveness

The Sprint Retrospective is the Scrum Team's dedicated time to look inward. It follows the Sprint Review and closes out the Sprint before the next one begins.

Timebox: Maximum 3 hours for a one-month Sprint.

Participants: The entire Scrum Team — Product Owner, Scrum Master, and Developers.

The Purpose, Precisely

The Scrum Guide says the Retrospective is about inspecting how the last Sprint went with regard to individuals, interactions, processes, tools, and the Definition of Done. The team identifies what went well, what problems they encountered, and — critically — commits to at least one improvement for the next Sprint.

That commitment to action is what separates a real Retrospective from a venting session. As a Scrum Master, your job is to facilitate a productive, psychologically safe environment where team members can speak honestly. This requires trust, Scrum values (courage, openness, respect), and techniques calibrated to the team's maturity and dynamics.

The Scrum Master's Unique Role Here

The Scrum Master participates in the Retrospective as a team member and as a facilitator. They're not just observing — they're accountable for the Scrum process itself, which means they have a stake in process improvements. At the same time, the Scrum Master must create space for Developers and the Product Owner to surface issues without judgment.

A common real-world failure: Retrospectives that produce long lists of improvements but no real change sprint over sprint. As a Scrum Master, you recognize this anti-pattern and work to help the team focus on fewer, more impactful improvements with clear ownership.

---

Timeboxing Rules for Scrum Events (Exam Cheat Sheet)

Timeboxes are non-negotiable in Scrum. Events can end early, but they cannot exceed their maximum duration. Memorize these for the exam:

Event	1-Month Sprint Maximum	Notes
Sprint	1 month	Fixed length, chosen by Scrum Team
Sprint Planning	8 hours	Scales proportionally
Daily Scrum	15 minutes	Every day, same time/place
Sprint Review	4 hours	Scales proportionally
Sprint Retrospective	3 hours	Scales proportionally

Key exam points:

• Events can end early if their purpose is achieved.
• No event should be extended beyond its timebox, even if work is unfinished.
• The Daily Scrum is always 15 minutes, regardless of Sprint length.

---

Common Exam Pitfalls: Who Must Attend Each Event?

Attendance questions are a reliable source of tricky exam items. Here's what you need to know clearly:

• Sprint Planning: Entire Scrum Team (Product Owner, Scrum Master, Developers). Others may be invited.
• Daily Scrum: Developers only. Scrum Master and Product Owner attend only if they're working as Developers.
• Sprint Review: Scrum Team plus key stakeholders (invited by Product Owner).
• Sprint Retrospective: Entire Scrum Team.

The biggest trap is the Daily Scrum. Many candidates assume the Scrum Master must attend or run it. They don't. The Developers own this event. The Scrum Master's role is to ensure it happens and that its purpose is understood — not to facilitate it daily.

---

How the 2020 Scrum Guide Changed Event Accountabilities

The 2020 revision made several shifts that directly affect how you should answer accountability questions on the PSM I and CSM:

1. Roles became "Accountabilities." Developer, Product Owner, and Scrum Master are no longer called "roles" — they're accountabilities. This reflects that these are areas of responsibility, not job titles.

2. "Development Team" became "Developers." The 2020 Guide dropped the three-layer structure (Scrum Team → Development Team + Product Owner + Scrum Master) and unified it. The Scrum Team consists of one Product Owner, one Scrum Master, and Developers.

3. Sprint Goal became more prominent. The Sprint Goal is now a commitment attached to the Sprint Backlog, with explicit emphasis that it cannot change during the Sprint.

4. Forecasts replaced commitments (in the right places). The Developers forecast what they can do in the Sprint. They commit to the Sprint Goal. That distinction matters for exam questions about accountability.

5. Three commitments were introduced: Product Goal (Product Backlog), Sprint Goal (Sprint Backlog), and Definition of Done (Increment).

Understanding these shifts helps you avoid answering based on pre-2020 frameworks that your workplace might still be using.

---

Key Takeaways

• The Sprint is the container for all other events; it cannot exceed one month.
• Sprint Planning addresses why, what, and how — in that order.
• The Daily Scrum is a 15-minute event owned by Developers, not the Scrum Master.
• The Sprint Review is a collaborative working session with stakeholders, not a demo or approval gate.
• The Sprint Retrospective produces at least one actionable improvement commitment.
• Timeboxes are maximums — events can end early.
• Only the Product Owner can cancel a Sprint.
• The 2020 Guide replaced roles with accountabilities and elevated the Sprint Goal significantly.

---

Conclusion

Mastering the five Scrum events isn't just about memorizing timeboxes and attendance lists — though you absolutely need those locked in before exam day. It's about understanding why each event exists and how it serves the principles of empiricism, self-management, and continuous improvement. When you understand the purpose behind the structure, scenario-based questions become far more intuitive.

The best way to solidify this knowledge is to practice with realistic, scenario-based Scrum Master questions that mirror the ambiguity and complexity of the actual PSM I and CSM exams. Reading the Scrum Guide is essential, but applying it to realistic situations — a manager who wants to join the Daily Scrum, a Product Owner who wants to change the Sprint Goal mid-sprint — is where the real learning happens. Seek out quality practice exams and work through the rationale behind every answer, right or wrong. That deliberate practice is what separates candidates who pass with confidence from those who barely scrape by.

---

Frequently Asked Questions

Q: Can the Scrum Master facilitate the Daily Scrum?

The Scrum Guide says the Developers are responsible for the Daily Scrum. The Scrum Master's job is to ensure it happens and that its purpose is understood. They can facilitate it temporarily — for example, when a team is new to Scrum — but the goal is always to build the team's self-management capability so they run it independently. On the exam, if a question asks who is responsible for the Daily Scrum, the answer is the Developers.

Q: Is the Sprint Retrospective the last event in the Sprint?

Yes. The Sprint Retrospective occurs after the Sprint Review and before the next Sprint Planning. It's the final event of the Sprint. Some candidates confuse this ordering, assuming the Retrospective happens at the beginning of the next Sprint. According to the 2020 Scrum Guide, it concludes the current Sprint.

Q: What happens to unfinished work at the end of a Sprint?

Incomplete Product Backlog items are returned to the Product Backlog. They are not automatically included in the next Sprint — the Product Owner re-evaluates and re-orders them. The Developers do not carry over unfinished work as a commitment; the next Sprint Planning starts fresh with the updated Product Backlog. This is a frequent source of exam confusion, particularly for candidates who come from traditional project management backgrounds where unfinished work "rolls over" automatically.