Understanding the four core agile meetings is the fastest way to improve how a Scrum team operates. Each ceremony has a distinct purpose, a different audience, and a different definition of success. Run them well and they compound. Run them poorly, or conflate one with another, and you'll find the same friction recurring sprint after sprint.
This guide covers Sprint Planning, the Daily Standup, the Sprint Review, and the Sprint Retrospective: what each one is for, how to run it effectively, and the most common mistakes to avoid.
The four types of agile meetings
| Meeting | When | Duration | Who facilitates |
|---|---|---|---|
| Sprint Planning | Start of each sprint | 1–2 hours | Scrum Master |
| Daily Standup | Every day | 15 minutes | Team (self-facilitated) |
| Sprint Review | End of sprint | 1–2 hours | Product Owner |
| Sprint Retrospective | End of sprint (after Review) | 1–2 hours | Scrum Master |
1. Sprint planning
What it is
Sprint Planning opens every sprint. The team reviews the product backlog with the Product Owner, agrees on a sprint goal, and selects the work they'll commit to delivering over the next one to four weeks.
The sprint goal is the most important output. A list of tickets is not a sprint goal. A sprint goal gives the team something to rally around when priorities shift mid-sprint.
What good looks like
- The sprint goal is agreed before the meeting ends; not "we'll figure it out as we go."
- Backlog items are well-refined; the team isn't spending planning time deciphering what a ticket means.
- Each selected item has a shared definition of done and a realistic estimate.
- The workload accounts for actual capacity: holidays, on-call duties, carry-over from last sprint.
Common mistakes
Over-committing. Teams that consistently miss their sprint goal are usually trying to do too much, not working too slowly. Use velocity data and honest capacity planning rather than optimism.
Skipping refinement. If Sprint Planning regularly runs long, the problem is usually under-refined backlog items. Too many unknowns in the room slow everything down.
No sprint goal. Without a shared goal, the team optimises for individual tickets rather than collective outcomes. When something unexpected comes up mid-sprint, there's no north star for triage decisions.
2. Daily standup
What it is
The Daily Standup is a 15-minute daily sync to coordinate the team's work and surface blockers. It is not a status report to the Scrum Master; it's a team-to-team conversation.
The classic three questions:
- What did I do yesterday?
- What will I do today?
- Is anything blocking me?
What good looks like
- The meeting starts and ends on time, every day.
- Blockers are named clearly, not buried. An unblocked blocker at day's end is far more expensive than a briefly uncomfortable 60 seconds at standup.
- The team talks to each other, not to the Scrum Master.
- Deeper discussions are taken offline immediately after, not explored in real time.
Common mistakes
Turning it into a status report. If the Scrum Master is asking the questions and team members are answering to them, it has become a reporting ceremony rather than a coordination tool.
Running over 15 minutes. If standups regularly overrun, the problem is usually updates that belong in a separate meeting. Apply the "take it offline" rule firmly.
Treating blockers as optional to mention. Teams that consistently say "no blockers" when blockers clearly exist have a psychological safety issue, not a standup issue. Address it in the retrospective.
3. Sprint review
What it is
The Sprint Review happens at the end of the sprint. The team demonstrates completed work to stakeholders and the Product Owner, and the backlog is adjusted based on what was built and what feedback was received.
The Sprint Review is the feedback loop between the team and the business. Without it, the team builds in a vacuum.
What good looks like
- Only work that meets the definition of done is demonstrated. Partially complete work is not shown.
- Stakeholders are actively engaged: asking questions and giving feedback, not watching a presentation.
- The Product Owner adjusts the backlog based on what they see and hear, not later in the week when the moment has passed.
- The discussion stays focused on the product, not the team's process (that's what the retrospective is for).
Common mistakes
Demoing work that isn't done. This erodes trust in the definition of done and teaches stakeholders to expect approximate rather than verified output.
One-way presentation. If stakeholders are passive observers, the review isn't working. The whole point is to get feedback that changes what the team builds next. Design the session to create dialogue.
No stakeholders present. A Sprint Review with just the development team is a rehearsal, not a review.
4. Sprint retrospective
What it is
The Sprint Retrospective is the team's space to reflect on how they worked, not what they built. It follows the Sprint Review and focuses on process, collaboration, and continuous improvement.
Three questions frame most retrospectives:
- What went well?
- What could be improved?
- What will we do differently next sprint?
The third question matters most. A retrospective without concrete action items is just a conversation.
What good looks like
- Action items from the previous retrospective are reviewed at the start.
- The team is honest, which requires psychological safety.
- The session produces two or three specific, owned action items, not a wishlist of ten.
- The format varies sprint to sprint. Rotating retrospective formats keeps the conversation fresh.
TeleRetro has 50+ retro formats and templates to suit different team moods and sprint types. TeleRetro's Retro Bot can suggest a format if you're not sure where to start.
Common mistakes
Same format every sprint. Familiarity breeds autopilot answers. Try rotating between Lean Coffee, Mad Sad Glad, or Sailboat to change what surfaces.
Action items with no owners. "We should improve the CI pipeline" is not an action. "Priya will investigate parallelising the test suite by next Thursday" is.
Stakeholders or managers in the room. Retrospectives are for the team. External presence changes what people say. Keep attendance to the team and Scrum Master by default.
How the four meetings connect
The four ceremonies form a cycle. Sprint Planning sets direction. Standups maintain coordination. The Sprint Review checks output against the product vision. The Retrospective improves how the team works so the next cycle is better than the last.
When one ceremony is weak, it puts pressure on the others. Teams with poor Sprint Planning tend to have chaotic standups. Teams without effective retrospectives repeat the same problems sprint after sprint. Treating the four meetings as a connected system, rather than four separate obligations, is what makes the agile cadence actually work.
Frequently asked questions
Are all four meetings required in agile?
In Scrum specifically, yes: all four ceremonies are defined in the Scrum Guide. In Kanban or other frameworks, the structure is more flexible. Many Kanban teams run a daily standup and a periodic retrospective but skip Sprint Planning and the Sprint Review in their traditional form. What matters is that the underlying purposes are met: coordination, feedback, and continuous improvement.
What's the difference between a sprint review and a sprint retrospective?
The sprint review is about the product: what got built, whether it meets the definition of done, and what stakeholders think. The retrospective is about the team: how you worked together, what slowed you down, and what to change. Different meetings, different participants, different outputs.
Who should attend each meeting?
- Sprint Planning: The development team, Scrum Master, and Product Owner.
- Daily Standup: The development team. The Scrum Master may attend but shouldn't drive it.
- Sprint Review: The development team, Scrum Master, Product Owner, and invited stakeholders.
- Sprint Retrospective: The development team and Scrum Master. The Product Owner may attend if the team invites them, but it's optional and should be the team's choice, not a default.
How long should each meeting be?
The Scrum Guide ties duration to sprint length. For a two-week sprint: Sprint Planning up to four hours, Sprint Review up to two hours, Sprint Retrospective up to 1.5 hours. In practice, experienced teams run shorter. Standups are always 15 minutes, regardless of sprint length.
Updated
Experience a better retro
Create a retro in seconds & see for yourself.