Call Us
Last updated: 7 October 2026.
Scrum has five events: the Sprint, Sprint Planning, the Daily Scrum, the Sprint Review and the Sprint Retrospective. The Sprint is the container, a fixed period of one month or less, and the other four events happen inside it. Every event is a formal chance to inspect progress and adapt the plan, and every event has a maximum length called a timebox.
Key Highlights
- Four formal events sit inside a containing event, the Sprint. That is why the count is given as both four and five.
- Each event exists to create a specific opportunity to inspect and adapt. An event that produces no change has stopped doing its job.
- Timeboxes are maximums, not targets. Finishing Sprint Planning in ninety minutes is a good outcome, not a shortcut.
- The Scrum Guide sets timeboxes for a one-month Sprint. Shorter Sprints run proportionally shorter events.
- The Sprint Review and the Sprint Retrospective are different events with different purposes, and merging them is the most common structural mistake.
- Skipping an event does not save time. It moves the cost somewhere less visible.
Four Events or Five?
You will see both numbers online, and the difference is a matter of counting rather than a disagreement about Scrum. Scrum.org and Scrum Alliance both list five events and describe the Sprint as the container for the rest. Other writers say four because Sprint Planning, the Daily Scrum, the Sprint Review and the Sprint Retrospective are the four bounded meetings with a start and an end, while the Sprint is a period in which work happens continuously.
For an exam or an interview, answer five, then add that four of them are meetings held inside the Sprint. That shows you understand the structure rather than a memorised list.
What does matter is understanding why the Sprint is treated differently. Sprint Planning, the Daily Scrum, the Review and the Retrospective are bounded meetings with start and end times. The Sprint is a period of time inside which work happens continuously. Grouping them as five identical things obscures that difference, which is presumably why the Guide separates them.
If you are working through the framework and want to check your grounding, our free CSM practice test covers the events and takes a few minutes.
Scrum Events vs Scrum Ceremonies
Scrum events and Scrum ceremonies are the same thing. The Scrum Guide uses the word events. Ceremonies is older, informal usage that is still common in job descriptions, tool documentation and everyday conversation. Scrum Alliance says it deliberately uses events to match the Guide.
In formal writing, exams and certification work, use events. In conversation and search, expect to meet both terms, and treat them as interchangeable.
The Events at a Glance
Timeboxes below are the maximums the Scrum Guide sets for a one-month Sprint. Shorter Sprints run proportionally shorter events, so the two-week figures are typical practice rather than prescribed.
| Event | Timebox, one-month Sprint | Typical, two-week Sprint | Who runs it |
| The Sprint | One month or less | Two weeks | Not applicable, it is the container |
| Sprint Planning | Maximum 8 hours | 2 to 4 hours | Scrum Master facilitates |
| Daily Scrum | 15 minutes | 15 minutes | The Developers |
| Sprint Review | Maximum 4 hours | 1 to 2 hours | Scrum Master facilitates |
| Sprint Retrospective | Maximum 3 hours | 1 to 1.5 hours | Scrum Master facilitates |
The Daily Scrum is the exception that does not scale with Sprint length. Fifteen minutes is fifteen minutes regardless.
The word to notice throughout is maximum. These are ceilings, not durations to fill. A team that consistently finishes Sprint Planning in half the time available and produces a clear plan is doing well, and stretching the session to use the allocation would make it worse.
Timeboxes are maximums for a one-month Sprint.
| Event | Purpose | What it inspects | What it adapts | Participants | Timebox |
| Sprint | Container that gives the team a steady rhythm and fast feedback | Frame in which every other event happens | Not applicable | Scrum Team | One month or less |
| Sprint Planning | Agree why the Sprint matters, what can be done and how | Product Backlog, Product Goal, Definition of Done | Sprint Backlog, Sprint Goal | Scrum Team | 8 hours |
| Daily Scrum | Check progress toward the Sprint Goal and plan the next day | Progress toward the Sprint Goal | Sprint Backlog | Developers | 15 minutes |
| Sprint Review | Inspect the Increment with stakeholders and decide what comes next | Increment, the Sprint, Product Backlog, progress toward the Product Goal | Product Backlog | Scrum Team and stakeholders | 4 hours |
| Sprint Retrospective | Find ways to improve how the team works | The Sprint, Definition of Done | Actionable improvements, Definition of Done | Scrum Team | 3 hours |
Each event is a formal opportunity to inspect and adapt, which supports the three pillars of Scrum: transparency, inspection and adaptation.
A common rule of thumb scales the maximums with Sprint length. These are ceilings, not targets, so end early when the purpose is met.
| Event | Rule of thumb | One-week Sprint | Two-week Sprint | One-month Sprint |
| Sprint Planning | 2 hours per week of Sprint | 2 hours | 4 hours | 8 hours |
| Daily Scrum | 15 minutes, whatever the length | 15 minutes | 15 minutes | 15 minutes |
| Sprint Review | 1 hour per week of Sprint | 1 hour | 2 hours | 4 hours |
| Sprint Retrospective | 45 minutes per week of Sprint | 45 minutes | 1.5 hours | 3 hours |
Note that our typical two-week planning range of 2 to 4 hours sits inside the 4-hour ceiling shown here.
The Sprint
The container. Everything else happens inside it.
What is a Sprint in Scrum?
A fixed period of one month or less in which a usable Increment is created and in which all the other events take place. A new Sprint starts as soon as the previous one ends.
How long is a Sprint?
One month or less. Two weeks is the most common length in practice.
What it is. A fixed length period, one month or less, during which a usable Increment is created. A new Sprint starts immediately after the previous one ends, with no gap.
Why it is fixed. Consistency is the point. A team with a stable Sprint length develops a rhythm and a reliable sense of how much fits. Changing the length repeatedly removes both.
What cannot happen. The Sprint Goal does not change once agreed, and quality does not drop. Scope can be renegotiated between the Product Owner and the Developers as more is learned, and that is intended rather than a failure.
The common mistake. Treating the Sprint as a deadline rather than a container. When the Sprint becomes a countdown to a delivery date, the events turn into progress checkpoints and the inspect and adapt purpose disappears.
Sprint Planning
Where the Sprint starts.
What happens in Sprint Planning?
The Scrum Team agrees why the Sprint is valuable, what can be delivered and how the work will get done. The output is a Sprint Goal, the selected Product Backlog items and a plan for delivering them.
Who attends Sprint Planning?
The whole Scrum Team. The Product Owner brings the ordered backlog and the value case, the Developers decide how much to take on, and the Scrum Master facilitates.
How long is Sprint Planning?
No more than eight hours for a one-month Sprint, and proportionally less for shorter Sprints. If the plan is clear sooner, end the event.
Purpose. Answer three questions: why this Sprint is valuable, what can be delivered, and how the work will get done.
Who attends. The whole Scrum Team. The Product Owner brings the ordered backlog and the value narrative, the Developers decide how much to take on, and the Scrum Master facilitates.
What comes out. A Sprint Goal, the selected backlog items, and a plan for delivering them.
The most common failure. Items arriving unrefined, which turns planning into refinement with the entire team present. That is the single largest cause of planning sessions that overrun, and the fix sits upstream in backlog refinement rather than in the session itself. The distinction between the two is covered in our comparison of refinement and Sprint Planning.
What good looks like. Short, decisive, and ending with a goal the team believes in. Detail on running it well is in our guide to Sprint Planning.
The Daily Scrum
The most misunderstood of the four.
What happens in the Daily Scrum?
The Developers inspect progress toward the Sprint Goal and adapt the plan for the next day. It is a planning conversation, not a report to a manager.
Who attends the Daily Scrum?
The Developers. The Product Owner and Scrum Master may attend as participants, but the event belongs to the Developers.
How long is the Daily Scrum?
Fifteen minutes every working day, whatever the length of the Sprint.
Purpose. The Developers inspect progress toward the Sprint Goal and adapt the plan for the next day. It is a planning session, not a reporting session.
Who attends. The Developers. The event belongs to them. The Product Owner and Scrum Master may attend, and if they do, they are there as participants rather than as an audience.
Timebox. Fifteen minutes, every working day, ideally at the same time and place to reduce the overhead of arranging it.
The failure that defines it. Turning into a status update to a manager or to the Scrum Master. The moment people start speaking to one person rather than to each other, the event stops functioning. The tell is easy to spot: watch where people look while they talk.
On the three questions. The familiar format of what I did, what I will do, and what is blocking me is a common technique rather than a requirement. Teams that find it produces mechanical recitation are free to use something else, provided the event still produces a plan for the day. Our guide to the Daily Scrum covers the alternatives.
The Sprint Review
Where the work meets the people who asked for it.
What happens in the Sprint Review?
The Scrum Team and stakeholders inspect what was built and discuss what to do next. The Product Backlog is adapted based on the conversation, so it is a working session rather than a one-way demo.
Who attends the Sprint Review?
The Scrum Team plus stakeholders such as users, customers and affected departments. It is the only event with regular outside attendance.
How long is the Sprint Review?
No more than four hours for a one-month Sprint. About one hour per week of Sprint length is a common rule of thumb.
Purpose. Inspect the Increment and adapt the Product Backlog. The Scrum Team and stakeholders review what was done and what changed, then discuss what to do next.
Who attends. The Scrum Team plus stakeholders. This is the event with external attendance, and getting the right people in the room is most of what makes it useful.
What it is not. A demo. The word demo suggests a presentation with an audience, which produces a one way session where the team shows and stakeholders watch. The Review is a working conversation about what should happen next, and the backlog should change as a result.
Common failures. Presenting slides instead of working software. Showing only what succeeded. Treating stakeholder feedback as a threat to the plan rather than as the input the event exists to collect.
What good looks like. Working functionality, honest discussion of what did not get done, and a backlog that looks different afterwards. More detail is in our guide to the Sprint Review meeting.
The Sprint Retrospective
The event that makes the others improve.
What happens in the Sprint Retrospective?
The Scrum Team looks at how the Sprint went across people, relationships, process and tools, then agrees improvements it will act on.
Who attends the Sprint Retrospective?
The Scrum Team only. Keeping stakeholders and managers out protects the honesty the event depends on.
How long is the Sprint Retrospective?
No more than three hours for a one-month Sprint, and roughly 45 minutes per week of Sprint length.
Purpose. Inspect how the last Sprint went in terms of people, relationships, process and tools, then identify what to improve.
Who attends. The Scrum Team only. No stakeholders and no managers, because the safety to be honest is the entire mechanism.
Timing. After the Sprint Review and before the next Sprint Planning, closing the Sprint.
The failure that kills it. Producing actions nobody completes. A team that generates a list every Sprint and finishes none of it has a ritual rather than an event, and the credibility loss is cumulative. One improvement genuinely completed beats five logged.
What good looks like. One or two specific, owned actions that get done before the next Retrospective, and enough safety that people raise real problems rather than comfortable ones. Our guide to the Sprint Retrospective covers formats and facilitation.
Review Versus Retrospective
These two get merged more often than any other pair, and the merge removes both.
| Sprint Review | Sprint Retrospective | |
| Subject | The product | The process and the team |
| Attendees | Team plus stakeholders | Team only |
| Question | Are we building the right thing? | Are we working well? |
| Output | An adapted Product Backlog | Improvements to how the team works |
Running them as one session means either stakeholders are present for a conversation about team dynamics, which stops it being honest, or the process discussion gets cut short because the product discussion overran. Both outcomes are worse than holding two shorter meetings. The full comparison is in our guide to Sprint Review versus Sprint Retrospective.
Scrum Events in Order
A Sprint begins with Sprint Planning, where the team agrees a Sprint Goal and a plan. The Daily Scrum then runs every working day so the Developers can adjust that plan. Towards the end of the Sprint, the Sprint Review brings in stakeholders and adapts the Product Backlog, and the Sprint Retrospective follows, closing the Sprint with an agreed improvement. The next Sprint begins immediately, with no gap.
Is backlog refinement a Scrum event?
No. Backlog refinement is an ongoing activity rather than a formal event, so it has no prescribed timebox or format. It matters because refined items make Sprint Planning shorter and calmer. Some articles list it as a fifth event, which is where much of the confusion comes from.
Techniques teams use inside the events
- Sprint Planning: planning poker is a popular way to estimate items. See our guide to planning poker.
- Sprint Retrospective: start, stop, continue asks what to begin, end and keep doing. The five whys digs from a symptom to a root cause. Choose one or two improvements and give each an owner.
- Daily Scrum: the three-question format is a technique, not a requirement. Any format works if it produces a plan for the day.
How a Two Week Sprint Fits Together
Seeing the events in sequence makes the design clearer than describing them individually.
Monday, week one, morning. Sprint Planning. The Product Owner opens with why this Sprint matters, the team works through the top of the backlog, selects what fits, and agrees a Sprint Goal. Two to three hours. The Sprint has now started.
Every morning after. Daily Scrum, fifteen minutes. The Developers look at where they are against the Sprint Goal and adjust the plan for the day. On day three someone mentions an item is larger than expected, and the team decides to pair on it rather than let it drift.
Midweek, both weeks. Refinement. Not a formal event, and it happens anyway, because the top of the backlog needs to be ready for the next planning session. An hour or so, usually part of the team rather than everyone.
Thursday, week two. Sprint Review. Stakeholders join. The team shows what works, is honest about what did not get finished, and the conversation turns to what matters next. The Product Owner reorders the backlog based on what came out of it.
Thursday, week two, later. Sprint Retrospective. Team only. They pick one thing that made the Sprint harder than it needed to be and agree a specific change with an owner.
Friday. The Sprint ends. The next one begins Monday with no gap.
Across a two-week Sprint, the four meetings add up to roughly 6.5 to 10 hours per person: about 2.5 hours of Daily Scrums (ten days at 15 minutes), 2 to 4 hours of Sprint Planning, 1 to 2 hours of Sprint Review and 1 to 1.5 hours of Retrospective. Against roughly 70 working hours, that is about 9 to 14 percent. Teams that end each event as soon as its purpose is met sit near the lower end, and the time replaces the ad hoc coordination meetings that otherwise fill the same space less efficiently.
The sequencing is deliberate. The Review comes before the Retrospective because what happened with the product informs the conversation about how the team worked. Both come before the next Planning because their outputs, an adapted backlog and an agreed improvement, are inputs to it.
Running the Events Remotely
Distributed teams run the same four events, and three things need deliberate handling.
The Daily Scrum drifts toward status reporting. Without a physical board to stand at, people default to reporting in turn to whoever appears to be leading. The fix is having something visual everyone looks at, so the conversation is about the work rather than about each person.
The Retrospective needs more structure, not less. Silence in a room reads as thinking. Silence on a call reads as absence, and people talk over each other or say nothing. Using a shared board where everyone writes before anyone speaks solves most of this, and it also stops the loudest voice setting the agenda.
The Sprint Review loses its informality. In person, stakeholders wander over and try things. Remotely, someone shares a screen and everyone watches. Getting stakeholders to interact with the work themselves, rather than watch a demonstration of it, takes deliberate effort and is worth the trouble.
What does not change is the timeboxes or the purposes. Remote events that overrun are usually suffering from the same causes as in person ones, most often unrefined items or a discussion that belongs somewhere else.
One thing genuinely improves remotely. Written input before discussion, which is awkward in a room and natural on a shared document, tends to produce more honest and more evenly distributed contributions. Several teams that adopted it remotely kept it afterwards.
Adapting the events to a team's circumstances without losing what they are for is a judgement call, and it is the kind of thing CSM Certification Training covers in more depth than a written guide can.
What the Events Have in Common
Understanding the shared purpose makes each one easier to run.
Every event is an opportunity to inspect and adapt. That is the entire design. If an event produces no adaptation, it is not doing its job regardless of how well attended it is.
Every event is timeboxed. The limits prevent open ended discussion and force the team to reach a conclusion.
Every event has a clear output. A plan, a goal, an adapted backlog, an improvement. An event that ends with nothing produced is a meeting.
Regularity reduces overhead. Holding events at consistent times removes the cost of arranging them and the need for other meetings to cover the same ground.
That last point is the answer to the most common objection, which is that Scrum has too many meetings. Four events across a two-week Sprint is roughly 6.5 to 10 hours per person in total. Teams that skip them almost invariably find the same conversations happening anyway, in ad hoc meetings, with fewer people present and no decisions recorded.
Common Mistakes Across the Scrum Events
Six that recur, in rough order of how much damage they do.
Treating timeboxes as targets. Filling the maximum because it is available. If the plan is clear after ninety minutes, finish.
Skipping the Retrospective under delivery pressure. The most self defeating choice available. The Retrospective is what fixes the reasons the team is under pressure, so cutting it guarantees the pressure continues.
Holding events because the framework requires them. Ritual without purpose. Every event should produce something, and if one consistently does not, the useful question is why it stopped rather than how to abandon it.
Letting the Scrum Master run the Daily Scrum. It belongs to the Developers. A Scrum Master who facilitates it indefinitely has created a dependency rather than a capability.
Inviting stakeholders to the Retrospective. Kills the safety that makes it work.
Allowing the Sprint Goal to change mid Sprint. Scope can be renegotiated, and the goal is what gives the team a basis for deciding what to protect when something goes wrong. Removing it removes that basis.
Noticing which of these is happening and addressing it without simply enforcing rules is most of the Scrum Master role during the Sprint, and it is covered practically in CSM Certification Training.
Conclusion
The events are easy to describe and harder to run well, and the difference is almost always about purpose rather than mechanics. A team can hold all four on schedule, within their timeboxes, and get nothing from them if none produces a change.
The most useful test is to ask what each event changed. Sprint Planning should produce a goal the team believes in. The Daily Scrum should change the plan for the day. The Review should change the backlog. The Retrospective should change how the team works. An event that changed nothing has told you something worth acting on.
The other thing worth resisting is the pressure to cut events when delivery gets tight. It feels like reclaiming time, and it reliably costs more than it saves, because the conversations still need to happen and they end up happening less visibly.
If you are running these events or preparing to, CSM Certification Training covers each one and the facilitation that makes them produce something rather than fill a slot. Request the curriculum to see the agenda and upcoming dates, or start with the free CSM practice test to see where your gaps are first.
Lowest-Price Challenge
Personalized Path
.webp){kind=small}
USA 
Canada
India
UK
Australia
Singapore
