Five Events Of Scrum

Scrum defines four formal events, and they all take place inside a fifth that contains them: the Sprint. The four are Sprint Planning, the Daily Scrum, the Sprint Review and the Sprint Retrospective. People commonly say five events because they count the Sprint itself, and the Scrum Guide describes the Sprint as a container for all other events rather than as one of them.

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.

Why the Count Is Confusing

Worth settling first, because it is the reason most people search for this.

The Scrum Guide combines four formal events for inspection and adaptation within a containing event, the Sprint. The Sprint is explicitly described as a container for all other events.

So the accurate statement is four events inside a fifth thing that holds them. Calling that four or five is a matter of counting rather than a disagreement about Scrum, and both usages appear widely. Nothing practical hangs on it.

Where it does matter slightly is in an exam or an interview. If asked to name the Scrum events, naming the four formal ones and noting that they sit within the Sprint demonstrates you understand the structure rather than having memorised a 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.

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.

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.

The Sprint

The container. Everything else happens inside it.

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.

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.

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.

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.

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.

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.

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.

Total time in events across the fortnight is roughly six to seven hours per person, against about seventy working hours. Under ten percent, and it 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 five to eight hours 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 All Four

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.

Closing Thoughts

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.