Overview
Scrum Events is the sixth SMPC learning-objective area and usually the most detailed in study materials. The 2020 Scrum Guide defines five events: the Sprint, which contains all the others, plus Sprint Planning, the Daily Scrum, the Sprint Review and the Sprint Retrospective. Each event is a formal opportunity to inspect and adapt Scrum artifacts, and all are designed to enable the transparency the pillars require. Holding events at the same time and place reduces complexity, and the events are meant to minimize the need for other meetings.
For each event you need its purpose, who attends, what goes in and what comes out, and its timebox. For a one-month Sprint, Sprint Planning is at most eight hours, the Sprint Review four hours and the Sprint Retrospective three hours; shorter Sprints usually need less. The Daily Scrum is 15 minutes regardless of Sprint length. CertiProf partner courses also cover techniques for facilitating Retrospectives.
How it's tested
Event questions mix recall and judgement. You may be asked for a timebox, who can cancel a Sprint, or what the output of Sprint Planning is. Scenario items describe a Daily Scrum turning into a status report, a Review run as a demo, or a team wanting to skip the Retrospective, and ask the Scrum Master's best response.
-
Timebox and rule recall
You pick a maximum duration, the event's purpose, or who has authority to cancel the Sprint.
-
Fix a dysfunctional event
An event drifts from its purpose, such as a Daily Scrum reporting to a manager, and you choose the corrective action.
-
Which event fits
A need such as revising the Product Backlog with stakeholders or improving the Definition of Done is described, and you name the event.
Mid-Sprint, the company changes strategy and the Sprint Goal becomes obsolete. A Developer suggests finishing the Sprint anyway to keep the cadence. The Scrum Guide says a Sprint could be cancelled if the Sprint Goal becomes obsolete, and only the Product Owner has the authority to cancel it. The better answer is that the Product Owner may cancel the Sprint, not that the team completes obsolete work.
Topics 5
Official topics from the CertiProf outline, in outline order.
6.1 The SprintThe fixed-length container for all Scrum work.
- What it means
- Sprints are the heartbeat of Scrum, where ideas are turned into value. They are fixed-length events of one month or less to create consistency, and a new Sprint starts immediately after the previous one ends.
- What to understand
- All work needed to achieve the Product Goal, including the other four events, happens within Sprints. During the Sprint, no changes are made that would endanger the Sprint Goal, quality does not decrease, the Product Backlog is refined as needed, and scope may be clarified and renegotiated with the Product Owner. Shorter Sprints limit risk and create more learning cycles. Only the Product Owner may cancel a Sprint, typically when the Sprint Goal becomes obsolete.
- How it shows up
- Expect questions on maximum length, what can change mid-Sprint and who may cancel.
- Common confusion
- Believing a Sprint can be extended to finish work or that the Scrum Master can cancel it.
6.2 Sprint PlanningPlanning the work of the Sprint, timeboxed to eight hours for a one-month Sprint.
- What it means
- Sprint Planning initiates the Sprint by laying out the work to be performed. The resulting plan is created by the collaborative work of the entire Scrum Team.
- What to understand
- The 2020 Guide frames three topics. Why is this Sprint valuable? The team crafts a Sprint Goal. What can be done this Sprint? Developers select items from the Product Backlog, considering past performance and capacity. How will the chosen work get done? Developers plan the work, often decomposing items into smaller units. The Sprint Goal, the selected items and the plan together form the Sprint Backlog. The Product Owner ensures attendees are prepared to discuss the most important items, and others may be invited to advise.
- How it shows up
- Items test the three topics, who selects work and what the outputs are.
- Common confusion
- Thinking the Product Owner decides how much work the Developers take into the Sprint.
6.3 Daily ScrumA 15-minute event for Developers to inspect progress toward the Sprint Goal.
- What it means
- The Daily Scrum is a 15-minute event for the Developers of the Scrum Team, held at the same time and place every working day of the Sprint. Its purpose is to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary.
- What to understand
- Developers may choose any structure and techniques, as long as the event focuses on progress toward the Sprint Goal and produces an actionable plan for the next day. If the Product Owner or Scrum Master are actively working on Sprint Backlog items, they take part as Developers. The Daily Scrum is not the only time Developers can adjust their plan; detailed discussions often follow in separate conversations. It improves communication, identifies impediments and promotes quick decisions.
- How it shows up
- Scenarios show the Daily Scrum used for status reporting or problem-solving at length, and ask how the Scrum Master should respond.
- Common confusion
- Treating the three classic questions as mandatory or the Scrum Master as the person who must run the Daily Scrum.
6.4 Sprint ReviewInspecting the outcome of the Sprint with stakeholders, timeboxed to four hours for a one-month Sprint.
- What it means
- The purpose of the Sprint Review is to inspect the outcome of the Sprint and determine future adaptations. The Scrum Team presents the results of its work to key stakeholders, and progress toward the Product Goal is discussed.
- What to understand
- During the event, the Scrum Team and stakeholders review what was accomplished and what has changed in their environment, then collaborate on what to do next. The Product Backlog may be adjusted to meet new opportunities. The Guide stresses that it is a working session and the Scrum Team should avoid limiting it to a presentation. It is the second-to-last event of the Sprint.
- How it shows up
- Questions ask about the event's purpose, the presence of stakeholders and whether it is a gate for releasing.
- Common confusion
- Thinking the Sprint Review is the only point at which value can be released or a sign-off meeting.
6.5 Sprint RetrospectivePlanning ways to increase quality and effectiveness, timeboxed to three hours for a one-month Sprint.
- What it means
- The Sprint Retrospective concludes the Sprint. Its purpose is to plan ways to increase quality and effectiveness by inspecting how the last Sprint went with regard to individuals, interactions, processes, tools and the Definition of Done.
- What to understand
- The Scrum Team discusses what went well, what problems it encountered and how those problems were or were not solved, then identifies the most helpful changes. The most impactful improvements are addressed as soon as possible and may be added to the next Sprint Backlog. Partner courses describe a five-stage facilitation flow: set the stage, gather data, generate insights, decide what to do and close the Retrospective, with techniques such as start, stop, continue.
- How it shows up
- Expect questions on who attends, what can be inspected and what happens with improvements.
- Common confusion
- Thinking improvements must wait for the Retrospective or that only process, not the Definition of Done, is inspected.
High-yield concepts
The terms, rules and formulas this domain turns into questions most often.
-
Sprint length
One month or less, fixed.
- Remember
- Next Sprint starts immediately after the previous one.
- Tested as
- Recall and change questions.
- Trap
- Extending a Sprint to finish work.
-
Sprint cancellation
Only the Product Owner may cancel a Sprint.
- Remember
- Usually when the Sprint Goal is obsolete.
- Tested as
- Authority questions.
- Trap
- Choosing the Scrum Master or stakeholders.
-
Sprint Planning timebox
Maximum eight hours for a one-month Sprint.
- Remember
- Shorter Sprints usually take less.
- Tested as
- Timebox recall.
- Trap
- Confusing with the Review's four hours.
-
Three Sprint Planning topics
Why, what and how.
- Remember
- The Sprint Goal comes from the why topic.
- Tested as
- 2020 change questions.
- Trap
- Recalling only what and how.
-
Daily Scrum
15 minutes for Developers, same time and place.
- Remember
- Any structure that focuses on the Sprint Goal.
- Tested as
- Dysfunction scenarios.
- Trap
- Making it a status report to the Scrum Master.
-
Sprint Review timebox
Maximum four hours for a one-month Sprint.
- Remember
- A working session with stakeholders.
- Tested as
- Purpose questions.
- Trap
- Treating it as a sign-off gate.
-
Sprint Retrospective timebox
Maximum three hours for a one-month Sprint.
- Remember
- Concludes the Sprint.
- Tested as
- Order and timebox items.
- Trap
- Placing it before the Sprint Review.
-
Retrospective inputs
Individuals, interactions, processes, tools and the Definition of Done.
- Remember
- The Definition of Done can be improved here.
- Tested as
- What-to-inspect questions.
- Trap
- Limiting it to people issues.
-
Event purpose
Each event is a formal chance to inspect and adapt.
- Remember
- Events reduce the need for other meetings.
- Tested as
- Why-events-exist items.
- Trap
- Adding extra status meetings.
-
Product Backlog refinement
An ongoing activity, not an event.
- Remember
- The Developers who will do the work are responsible for sizing items.
- Tested as
- Event-count questions.
- Trap
- Counting refinement as a sixth event.
Side by side
Concepts candidates mix up, compared on the point that decides the answer.
Event timeboxes for a one-month Sprint
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Sprint Planning | Sets the Sprint Goal and plan | Up to 8 hours | Mixing with Review time |
| Daily Scrum | Inspects progress toward the Sprint Goal | 15 minutes, any Sprint length | Scaling it with Sprint length |
| Sprint Review | Inspects outcome with stakeholders | Up to 4 hours | Running it as a demo only |
| Sprint Retrospective | Plans quality and effectiveness improvements | Up to 3 hours | Holding it before the Review |
Sprint Review vs. Sprint Retrospective
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Sprint Review | What was built and what to do next | Product focus with stakeholders | Discussing team process here |
| Sprint Retrospective | How the team worked | Process, people, tools and Definition of Done | Inviting stakeholders by default |
Exam traps
Each trap is an answer that looks right. Learn the clue that should change your mind.
-
Extend the Sprint
- What candidates pick
- Adding days so the team can finish committed items.
- Why it looks right
- It seems to protect delivery.
- Why it's wrong
- Sprints have a fixed length; unfinished items return to the Product Backlog and the next Sprint begins immediately.
Clue to watch for Work not done by the last day.
-
Scrum Master runs the Daily Scrum
- What candidates pick
- The Scrum Master asking each Developer for status.
- Why it looks right
- Facilitation looks like leadership.
- Why it's wrong
- The Daily Scrum is for Developers; the Scrum Master ensures it happens and teaches them to keep it within 15 minutes.
Clue to watch for Developers reporting to one person.
-
Review as sign-off
- What candidates pick
- Stakeholders formally accepting or rejecting the Increment.
- Why it looks right
- Similar to phase-gate reviews.
- Why it's wrong
- The Review is a working session to inspect the outcome and adapt the Product Backlog, not an approval gate.
Clue to watch for Words like approve or sign off.
-
Skip the Retrospective
- What candidates pick
- Dropping it when things go well.
- Why it looks right
- It saves time.
- Why it's wrong
- The Retrospective is a mandatory event; there is always something to improve, and skipping it removes an adaptation point.
Clue to watch for A high-performing team claims no issues.
-
Product Owner sets the amount of work
- What candidates pick
- The Product Owner deciding how many items enter the Sprint.
- Why it looks right
- They own the backlog.
- Why it's wrong
- Developers select how much they can do based on capacity and past performance; the Product Owner clarifies and orders.
Clue to watch for Who decides how much.
-
Refinement as an event
- What candidates pick
- A sixth event called refinement.
- Why it looks right
- Teams often schedule it.
- Why it's wrong
- Refinement is an ongoing activity in the Sprint, not one of the five Scrum events.
Clue to watch for Questions asking how many events exist.
Answer framework
Work through these steps for any question about a Scrum event, its rules or a dysfunction within it.
- Identify the event and restate its purpose in one phrase, such as inspecting progress toward the Sprint Goal for the Daily Scrum.
- Recall who attends and who decides: Developers own the Daily Scrum and the plan, the Product Owner owns ordering and cancellation.
- Check the timebox for the stated Sprint length, remembering that the Daily Scrum stays at 15 minutes whatever the length.
- If the event is drifting from its purpose, choose an answer where the Scrum Master teaches or coaches rather than taking control of the event.
- Reject options that extend the Sprint, skip an event, add sign-off gates or count Product Backlog refinement as a separate event.
Practice question
Want more like this? The SMPC practice test has questions for every domain.
Checklist
0 of 12
Tick each one you can do without notes. Your ticks stay in this browser.
Study strategy
Build an event grid with one row per event and columns for purpose, participants, inputs, outputs and maximum timebox. Fill it from the Scrum Events section of the 2020 Scrum Guide, not from memory, then test yourself by covering columns. Timeboxes are easy marks, so drill them until they are automatic, including the rule that shorter Sprints usually need shorter events.
Next, study the rules around the Sprint itself: what may change during a Sprint, what may not, and the cancellation rule. These generate several judgement questions because the wrong answers sound practical.
Then practise dysfunction scenarios. For each event, write one way it typically goes wrong, such as a Review run as a slideshow, and the Scrum Master's best response. Finally, learn the five Retrospective stages from your course material and one technique for each. This area likely carries the largest share of SMPC questions, so plan the most study time here.
FAQ
How many SMPC questions focus on Scrum Events?
CertiProf does not publish a weight for Scrum Events. Events are the most rule-dense part of the Scrum Guide, so this guide estimates around seven of the 40 questions, an editorial figure.
What are the timeboxes for a one-month Sprint?
Sprint Planning up to eight hours, Daily Scrum 15 minutes, Sprint Review up to four hours and Sprint Retrospective up to three hours.
Who can cancel a Sprint?
Only the Product Owner, usually when the Sprint Goal becomes obsolete.
Are the three Daily Scrum questions required?
No. The 2020 Guide lets Developers choose any structure, as long as the event focuses on progress toward the Sprint Goal and yields an actionable plan.
Is Product Backlog refinement an event?
No. It is an ongoing activity that adds detail, order and size to backlog items. Scrum has five events.
Does the Scrum Master have to attend the Daily Scrum?
No. The Scrum Master ensures it takes place and teaches the Developers to keep it within the timebox, but the event is for the Developers.
Other Agile & Scrum certifications
Where the same subject shows up in other exams. Cards marked "Same subject" open the matching domain.
Test your Domain 6 knowledge
Drill SMPC questions on event timeboxes, Sprint cancellation and dysfunctional events until every rule comes to mind without hesitation.