Scrum Ceremonies: The Five Events and How Long Each Should Take

Scrum ceremonies are the five events the Scrum Guide defines: the Sprint, which contains the other four, Sprint Planning, the Daily Scrum, the Sprint Review and the Sprint Retrospective. Each has a timebox, a maximum length. For a one-month Sprint the Guide sets eight hours for Sprint Planning, 15 minutes for the Daily Scrum, four hours for the Sprint Review and three hours for the Retrospective, and the Sprint itself is one month or less. For shorter Sprints the Guide says the events are “usually shorter”, except the Daily Scrum, which stays at 15 minutes.

Ceremonies, events or meetings: the same five things

The Scrum Guide↗ (opens in a new tab) never says “ceremony”. It says events, and explains that “Events are used in Scrum to create regularity and to minimize the need for meetings not defined in Scrum.” The word ceremonies is common in tools and training: Atlassian’s agile guide↗ (opens in a new tab), for one, calls them ceremonies and scrum meetings. Whatever your team calls them, they are the same events.

One difference in counting is worth knowing. Atlassian lists four main ceremonies, the four meetings. The Guide counts five events, because the Sprint is an event too: “The Sprint is a container for all other events.” Both are describing the same structure; the Guide simply treats the time box around the meetings as part of the framework.

The five Scrum events at a glance

• The Sprint. A fixed length of one month or less; a new Sprint starts as soon as the last one ends. Every other event happens inside it, and only the Product Owner can cancel it.
• Sprint Planning. Up to eight hours for a one-month Sprint. The whole Scrum Team answers why this Sprint is valuable, what can be Done and how, and leaves with a Sprint Goal, the selected items and a plan. Sprint planning meeting has an agenda and a template.
• Daily Scrum. 15 minutes, every working day, for the Developers. They inspect progress toward the Sprint Goal and adjust the plan for the next day. Daily standup covers what to say and when to skip it.
• Sprint Review. Up to four hours. The team shows the outcome to key stakeholders and they decide together what to do next; the Guide calls it “a working session” that should not be limited to a presentation. Sprint review vs retrospective separates it from the next event.
• Sprint Retrospective. Up to three hours, and it closes the Sprint. The Scrum Team looks at how it worked and picks the most helpful changes. Sprint retrospective questions has formats that get honest answers.

How long each should take for a two-week Sprint

The Guide gives timeboxes only for a one-month Sprint. Many teams scale them in proportion to Sprint length, which for a two-week Sprint gives the figures below. Treat them as ceilings, not targets: a small team with a well-refined backlog often finishes well inside them.

• Sprint Planning: up to four hours, often about two.
• Daily Scrum: 15 minutes. The Guide sets this regardless of Sprint length.
• Sprint Review: up to two hours.
• Sprint Retrospective: up to an hour and a half.

A timebox means the event stops when the time is up. The Agile Alliance glossary↗ (opens in a new tab) puts the rule plainly: “work should stop at the end of the timebox,” and the team then reviews what it achieved. An event that keeps overrunning is telling you something, usually that the work going into it was not ready.

Agile ceremonies outside the five

Teams often add meetings and call them ceremonies too. They can be useful, but none is a Scrum event:

• Backlog refinement. The Guide calls it “an ongoing activity,” not an event, so many teams hold a short session each week. Backlog refinement covers how.
• Estimation sessions such as planning poker. A technique for sizing, which the Guide leaves to the Developers.
• Demo days and release meetings. Often folded into the Sprint Review; the Guide says the Review “should never be considered a gate to releasing value.”
• Kanban’s cadences. The Kanban Guide↗ (opens in a new tab) requires no events at all: it says there is “no requirement” to wait for a formal meeting at a regular cadence to change the workflow.

Skipping a ceremony safely

The Guide is blunt: “Failure to operate any events as prescribed results in lost opportunities to inspect and adapt.” Each event is where one kind of feedback happens, so skipping one removes that feedback rather than just saving an hour. If time is short, shorten the event before you drop it, and if you drop it, replace what it did:

• Skip Sprint Planning and nobody agrees on a Sprint Goal, so the Sprint becomes a list. Minimum replacement: the Product Owner proposes a goal in writing and the Developers confirm what they can take on.
• Skip the Daily Scrum and blockers wait a day or more to surface. Minimum replacement: each Developer updates the board and posts one line on progress toward the goal, read by the others before noon.
• Skip the Sprint Review and stakeholders stop shaping the backlog. Minimum replacement: send the finished work with two questions, what should change and what matters next, and act on the answers.
• Skip the Retrospective and the same problems recur every Sprint. Minimum replacement: a 20-minute written retro with one change agreed on.

If you find you are skipping most of them, you are probably running Kanban with Sprint labels. That is a legitimate choice; Kanban vs Scrum helps you decide, and the Scrum Guide, summarized shows which parts are required for the result to still be called Scrum.

A one-page Scrum events cheat sheet

EVENT          WHO                      MAX (1-MONTH)  2-WEEK SPRINT  OUTPUT
Sprint         whole Scrum Team         1 month        2 weeks        a usable Increment
Planning       whole Scrum Team         8 h            up to 4 h      Sprint Goal + items + plan
Daily Scrum    Developers               15 min         15 min         plan for the next day
Review         team + key stakeholders  4 h            up to 2 h      adjusted Product Backlog
Retrospective  whole Scrum Team         3 h            up to 1.5 h    changes to how we work

ORDER   Planning -> Daily Scrum (every working day) -> Review -> Retrospective
        then the next Sprint starts immediately

QUESTION EACH EVENT ANSWERS
Planning ....... Why is this Sprint valuable, what can be Done, and how?
Daily Scrum .... Are we on track for the Sprint Goal, and what do we do today?
Review ......... What did we deliver, what changed, and what next?
Retrospective .. How do we work better next Sprint?

IF YOU SKIP IT, YOU LOSE
Planning ....... a shared goal       Daily Scrum .... early warning of blockers
Review ......... stakeholder input   Retrospective .. improvement

Running the events from a fenbs board

fenbs has no sprints, no meeting features and no burndown chart; it is a board with four fixed lanes, To Do, Next Up, In Progress and Completed. It works as the shared screen for each event:

• Sprint Planning: move the selected tasks from To Do into Next Up and order them. The Sprint Goal goes on the Decisions and rules page, where every connected AI assistant reads it before starting work.
• Daily Scrum: open In Progress and check History, which records who moved what and when, including moves made by an AI assistant.
• Sprint Review: walk the Completed lane. Copy as Markdown copies the board, so you can paste it into the invitation or the notes.
• Retrospective: record each change the team agrees to keep as a rule on the Decisions and rules page, decided by a person, and file the rest as enhancement tasks with a plan.