Scrum ceremonies: a complete guide to all 5 events

Illustrated team of developers gathered around a scrum board with sticky notes, progressing through different meeting formats in a colorful agile workspace Scrum defines exactly five events. Not four, not six. Each one exists for a specific reason, and skipping any of them leaves a gap in the feedback loop that makes scrum work. Here's what each event is for, who shows up, how long it takes, and the mistakes that quietly derail teams.

The sprint

The sprint is the container for everything else. Every other scrum event happens inside a sprint. It's a fixed timebox, usually one to four weeks, where the team builds a potentially shippable increment of the product. Key details:

Length: 1-4 weeks (2 weeks is the most common)
Who's involved: The entire scrum team
Output: A done increment

Sprints don't get extended. If the team can't finish everything, items go back to the backlog. This constraint is the point. It forces hard conversations about scope and priority early, rather than letting deadlines quietly slip. Shorter sprints (one or two weeks) reduce risk because you get feedback faster. Longer sprints give more room for complex work. Most teams land on two weeks and never look back.

When to shorten your sprint

If your team consistently carries unfinished work into the next sprint, try shorter sprints. It's easier to plan accurately for one week than four, and you'll catch scope problems sooner.

Sprint planning

Sprint planning kicks off each sprint. The team decides what to build and how to build it. Key details:

Timebox: Up to 8 hours for a 4-week sprint (scale down proportionally, so ~2 hours for a 2-week sprint)
Who's involved: Product Owner, Scrum Master, Development Team
Output: The sprint goal and sprint backlog

The meeting has two parts. First, the Product Owner presents the highest-priority backlog items and the team discusses what's achievable. Second, the developers break those items into tasks and figure out the approach. The sprint goal matters more than the individual items. It gives the team direction and the flexibility to negotiate scope if surprises come up mid-sprint.

How planning poker fits in

Many teams use planning poker during or before sprint planning to estimate backlog items. Each team member independently estimates story points, then the group discusses any large differences. This exposes assumptions and misunderstandings before work begins. Learn more about how planning poker works and the story point scales teams use.

Common mistake

Don't let sprint planning become a backlog grooming session. Items should already be refined and estimated before they enter planning. If half the meeting is spent clarifying requirements, your refinement process needs work.

Daily scrum

The daily scrum (or daily standup) is a 15-minute sync for the development team. It's not a status report to management. Key details:

Timebox: 15 minutes, same time and place every day
Who's involved: Development Team (Scrum Master facilitates if needed, Product Owner optional)
Output: Shared understanding of progress and blockers

The classic format is three questions: What did I do yesterday? What am I doing today? What's blocking me? But this format can get stale. Some teams walk the board instead, focusing on tickets rather than people. Others use async formats for distributed teams. The daily scrum exists to help developers coordinate. If someone's stuck, the team figures it out together. If two people are about to work on conflicting changes, they catch it here instead of in a merge conflict.

The async standup alternative

For remote and distributed teams, async standups are replacing the traditional morning meeting. Team members post updates on their own schedule, and the whole team stays informed without fighting timezone math. If you go async, writing updates that people actually read is a skill worth developing. Check out how to write standup updates that get read.

Illustrated split-screen showing a traditional standup circle on one side and team members posting async updates from different locations on the other, connected by flowing lines

Sprint review

The sprint review happens at the end of the sprint. The team demonstrates what they built to stakeholders and collects feedback. Key details:

Timebox: Up to 4 hours for a 4-week sprint (~1-2 hours for a 2-week sprint)
Who's involved: Scrum team + stakeholders (users, management, other teams)
Output: Feedback on the increment, updated product backlog

This is not a formal presentation. It's a working session where stakeholders use the actual product, ask questions, and tell you what they think should change. The Product Owner uses this feedback to adjust the backlog. Teams that skip or phone in sprint reviews tend to drift away from what users actually need. You can plan in a vacuum for only so long before you're building the wrong thing.

Sprint review vs. sprint demo

People use these terms interchangeably, but the Scrum Guide describes a collaborative working session, not a one-way demo. The difference matters. A demo is passive. A review is interactive. Stakeholders should leave with opinions, and the team should leave with information they can act on.

Who should be there?

Invite anyone who cares about the product. Engineering leads, designers, customer success, even actual customers if possible. The more diverse the feedback, the better your next sprint will be.

Sprint retrospective

The retrospective is where the team inspects itself. What went well? What didn't? What should change? It's the one event focused entirely on how the team works rather than what they're building. Key details:

Timebox: Up to 3 hours for a 4-week sprint (~90 minutes for a 2-week sprint)
Who's involved: Scrum Master, Development Team (Product Owner optional but recommended)
Output: Action items for the next sprint

A good retro produces one or two concrete action items. Not a wishlist. Not vague commitments like "communicate better." Specific, assignable changes that the team actually follows through on. For a deeper dive, see our guide to running an effective retrospective. If your retros feel repetitive, try mixing up the format with fresh retrospective ideas or starting with ice breaker questions to warm people up before the real discussion.

Illustrated team sitting in a circle with thought bubbles containing green checkmarks and red flags, voting on sticky notes on a board

Making retros safe

Retrospectives only work when people feel safe being honest. Anonymous feedback and voting help. So does setting ground rules at the start: no blame, no interruptions, all perspectives welcome. If team members hold back, the retro becomes a formality instead of a tool. Kollabe's retrospective boards support anonymous submissions and voting by default, which helps quieter team members contribute without pressure.

Track your action items

The biggest retro killer is never following up on action items. Pick one or two changes per sprint and assign a specific person to each. Review last sprint's actions at the start of every retro.

How the five events connect

These events aren't isolated meetings. They form a cycle:

Event	Input	Output
Sprint planning	Refined backlog, previous feedback	Sprint goal + sprint backlog
Daily scrum	Yesterday's progress, today's plan	Coordination, blocker resolution
Sprint review	Done increment	Stakeholder feedback, backlog updates
Sprint retrospective	Team observations	Process improvements
Sprint	Everything above	Shippable increment

Sprint review feedback flows into backlog prioritization. Retrospective action items change how the next sprint runs. Daily scrums surface problems that get addressed the same day. Remove any event and the cycle breaks.

Common mistakes across all ceremonies

😴Going through the motions

Holding events because scrum says to, without genuine engagement. If nobody's paying attention, the meeting is waste.

⏰Ignoring the timeboxes

A 15-minute standup that runs 45 minutes isn't a standup. Timeboxes exist to force focus. Use a timer.

🚫Skipping events when busy

The sprint where you "don't have time for a retro" is the sprint that needed one most.

👥Wrong audience

Stakeholders in the daily scrum, developers missing from sprint review. Each event has a defined audience for a reason. See our guide on who should attend a retrospective.

Quick reference

Event	Timebox (2-week sprint)	Participants	Frequency
Sprint	2 weeks	Entire scrum team	Continuous
Sprint planning	~2 hours	PO, SM, Dev Team	Start of sprint
Daily scrum	15 minutes	Dev Team	Every day
Sprint review	~1-2 hours	Scrum team + stakeholders	End of sprint
Sprint retrospective	~90 minutes	SM, Dev Team, PO (optional)	End of sprint, after review

Wrapping up

Scrum ceremonies work as a system. Each event feeds the next, and together they create a loop of plan, build, get feedback, adjust. Understand each one on its own, but pay attention to how they connect. If you want better tooling for your ceremonies, Kollabe handles estimation, retrospectives, and standups in one place.

Yes. The Scrum Guide uses "events" as the official term, but "ceremonies" is widely used in practice. They refer to the same five activities: the sprint, sprint planning, daily scrum, sprint review, and sprint retrospective.

Each event has a specific role in the inspect-and-adapt cycle. Skip sprint reviews and you build the wrong thing. Skip retros and process problems never get fixed. Skip planning and nobody agrees on the goal. They work as a set.

The daily scrum is the easiest to move async, especially for distributed teams. Sprint planning and retrospectives benefit from real-time discussion but can use hybrid approaches where input is gathered async and decisions are made synchronously. Sprint reviews are hardest to do async since live feedback is the whole point.

Larger organizations using frameworks like SAFe or LeSS add coordination events on top of the core five. But at the individual team level, the ceremonies stay the same. Each scrum team (ideally 3-9 people) runs its own set of events regardless of company size.

Last Updated on 09/02/2026