Editor’s note: This blog was updated on 23 September 2024 to update and re-organize information, as well as create summary tables.
According to The Scrum Guide, scrum is a framework within the agile methodology that allows teams to deliver complex products and features quickly and efficiently. In the world of product management, the scrum framework is an invaluable tool for delivering complex products and features both rapidly and efficiently. Regardless of the variations in each organization’s framework and methodology, core scrum meetings continue to fill up calendars across the industry.
Scrum meetings are a type of meeting in agile. This comprehensive guide will introduce the fundamental concept of scrum and delve deeper into each of the five essential scrum meetings: sprint planning, daily scrum, sprint review, sprint retrospective, and backlog refinement.
The term “scrum meeting” describes all regular meetings held by scrum teams. The purpose of these meetings is to ensure smoother product management and development with complete transparency and autonomy.
In addition, scrum meetings help foster collaboration while setting shared expectations and delivery goals for the development teams. The five scrum meetings are sprint planning, daily scrum, sprint review, sprint retrospective, and product backlog refinement, in that order during a sprint execution:
We’ll go into detail about each of them momentarily.
To better understand the purpose of the five scrum meeting types, it’s first essential to understand what sprints are.
According to The Scrum Guide, a typical development cycle is 2–3 weeks and can go up to one month. This period of development is called a sprint or an iteration. Sprints are short and mainly focus on quick, incremental delivery, with faster learning and iteration instead of long, full-scale product development and delivery:
Specifically, working in sprints helps prevent teams from creating unnecessary features. The nature of working in sprints prioritizes iterative development and regular feedback, ensuring that the team’s focus stays on delivering high-value functionality that aligns with stakeholder needs.
As mentioned above, there are five types of meetings in scrum, also called ceremonies. These meetings are designed to promote collaboration, boost efficiency, and optimize the product development process to produce maximum value for the end user.
Let’s zoom in on each scrum ceremony with a focus on the product manager’s role in implementing and executing an agile product development strategy.
A sprint planning meeting is an important scrum ceremony in which the scrum team decides what work it will commit to in the upcoming sprint — roughly the next 2–3 weeks.
The sprint planning ceremony is usually led by the product manager, product owner, or scrum master. All members of your scrum team should be there, including engineers, QAs, and designers — each of whom is critical to the sprint planning process.
Sprint planning meetings are usually full-day events for a month’s sprints but can be proportionately shorter — two hours of sprint planning for each week of the sprint.
During sprint planning, the product owner runs through the prioritized backlog, one user story at a time, and explains to the technical team the value they will create via each story. Then, the developers, testers, and designers break down the user story into actionable tasks and subtasks.
Once the developer creates all the subtasks, they unanimously estimate each user story on a point system agreed upon by the team. Essentially, the scrum team is reviewing work and determining their capacity.
A common example of a point system framework is to use T-shirt sizes (S, M, L, and XL). A team might even use actual points — 2, 5, 8, 13, etc. — based on an established, common understanding of what the points represent and how they are measured.
It’s important to note that these estimation points don’t indicate time. Instead, they represent the complexity of the tasks, uncertainties, and dependencies.
After estimating all the prioritized tasks in the backlog, the scrum master pulls the user stories into the sprint backlog based on the agreement with the team members. Finally, the team members set up a goal for the sprint and the sprint begins. Note that while some teams still hold sprint goals in high regard, they’re not always necessary.
The goal of the sprint is to produce and deliver value for the end user, so it is not a sprint goal to complete all tasks in the sprint.
After the sprint planning meeting, every team member should have a clear view of the sprint backlog — i.e., what will be developed and delivered in the next sprint, along with a common sprint goal stating the user value connected to the delivery.
Pro tip: It is easier to have an effective sprint planning meeting if priorities have already been determined and the backlog is groomed with complete information regarding each user story. The product owner should be prepared with the required details and information to help the dev team better understand the story and avoid confusion.
| Summary: Sprint planning | |
|---|---|
| Definition and purpose | Plan, estimate, and agree upon the deliverables of the upcoming sprint |
| Duration | Two hours of sprint planning for each week of the sprint. For a four-week sprint (one month), this will be an eight-hour, full-day meeting |
| Participants and roles | The entire scrum team, including the product owner, scrum master, developers, testers, designer, and anyone else involved in building or developing the product or feature |
| Key steps and outcomes | 1. Go through user stories from the prioritized backlog
2. Create tasks and subtasks 3. Estimate user stories 4. Pull agreed-upon stories into the sprint 5. Set a sprint goal 6. Start the sprint The primary outcome of sprint planning is to establish a common sprint goal for team members based on priorities, team velocity, and value realization to the end user |
The daily scrum — also known as the daily standup — is a 15-minute time-boxed meeting. During this meeting, each team member has the opportunity to share the progress they have contributed toward meeting the sprint goal, along with the plan for the day.
The most important function of the daily scrum meeting is to raise any impediments that might hinder your team from achieving its daily objective.
The participants in the daily scrum are the scrum master and the development team. The product owner and other stakeholders can attend if needed, but are not required to be present.
The daily standup is organized and monitored by the scrum master. It’s the scrum master’s responsibility to keep the meeting on task and avoid letting the discussion devolve into tangential areas.
The maximum time allocated for a daily scrum is 15 minutes.
One format of the daily scrum that suits this agenda, as established in previous editions of The Scrum Guide, has each team member answer three questions:
Pro tip: The daily standup is not a reporting meeting. Because participants are asked the same three stock questions every day, the daily scrum can become monotonous. When discussing these questions, try to present your answers as a dialogue instead of simply listing off updates.
| Summary: Daily scrum | |
|---|---|
| Definition and purpose | Share the progress that each team member has contributed toward meeting the sprint goal, along with the plan for the day |
| Duration | 15 minutes, once per day |
| Participants and roles | The scrum master and the development team (required). The product owner and other stakeholders may join if they’d like, but it’s optional |
| Key steps and outcomes | Answer these three questions about the work toward the sprint goal:
|
As the name suggests, the sprint review meeting is where the development team reviews the work it has done during the sprint. They demo it for stakeholders and address any questions they may have while inspecting the development.
The demo provides a chance for stakeholders to see the feature in action for the first time. The development team also discusses whether the work is completed or if additional changes are required, as well as any remaining impediments.
In a more standard setup, the product owner walks through all the tasks completed during the sprint, developers demo it, and stakeholders inspect and give feedback. Sometimes, this feedback is added to the product backlog for future sprints.
The sprint review is attended by the scrum team and key stakeholders. All attendees have an active role in running the meeting. It should be communicative and collaborative among all attendees.
When the sprint review is arranged, the product owner sends invitations to all the required participants, including all stakeholders. The product owner is also responsible for facilitating the review of the marketplace or potential product use that might have changed, reasoning out the next-best valuable delivery.
The sprint review is the second-to-last event of the sprint. It’s time-boxed to a maximum of four hours for a one-month sprint, though it’s usually shorter for shorter sprints.
To foster a productive meeting, it’s a good idea to send a detailed sprint review meeting agenda with the meeting invitation. That way, all parties involved can prepare ahead. Here’s a template for a sprint review meeting agenda that you can reference when planning your own meetings.
In addition to facilitating the review of the marketplace or potential product use, there should also be a review of the timeline, budget, and potential capabilities for the next anticipated releases of functionality and capability of the product.
Pro tip: For a more efficient meeting, prepare the demo well beforehand with all the test cases planned to be demoed. Then, perform a final check on all systems, assuring that everything is up and running so you can demo without hindrance.
| Summary: Sprint review | |
|---|---|
| Definition and purpose | Scrum team discusses and demonstrates the work completed during the sprint, and stakeholders provide feedback |
| Duration | Four hours or less |
| Participants and roles | The entire scrum team, including the product owner, scrum master, developers, testers, designer, and any relevant stakeholders |
| Key steps and outcomes | 1. Scrum team presents completed user stories and discusses unfinished ones
2. Development team shares successes, challenges, and implemented solutions 3. Developers demonstrate work and answer stakeholders’ questions 4. Product owner reviews the product backlog and discusses project timelines 5. Group collaboration on next steps The outcome of this meeting is to arrive at a revised product backlog and adjusted priorities for the next sprint |
The sprint retrospective (aka the retro) is held at the end of a sprint to evaluate what went well in terms of processes followed, people involved, tools used, collaboration, and relationships. Your team should also reflect on anything that must be improved upon in the next sprint for more efficient delivery.
Based on this reflection, the team compiles a list of things that went well, what didn’t go well, and what to potentially improve.
Anything and everything that can improve the team’s work methods and boost efficiency in development is up for discussion. The sprint retrospective provides an opportunity to discuss and plan for these modifications before the team gets lost in the rush for the next delivery.
The entire development team participates in the sprint retrospective, including the tester, designer, product owner, and scrum master, who facilitates the meeting. The scrum master also acts as a scrum coach for the team, ensuring that the team is adhering to the agreed-upon ways of working to create efficiency in the development.
The sprint retrospective is a time-boxed event and can be anywhere from one to three hours, depending on the length of the sprint.
The outcome of a sprint retrospective should be a clear list of actions for improvement that the team can take into the next sprint.
Pro tip: The sprint retrospective is an intimate meeting among the scrum team members. Therefore, the meeting’s discussions should be respectful and general, avoiding personal incursions. It is crucial that team members feel comfortable sharing their views without getting reprimanded or blamed in this meeting.
| Summary: Sprint retrospective | |
|---|---|
| Definition and purpose | Reflect on and improve processes within the scrum team |
| Duration | 1–3 hours |
| Participants and roles | The entire scrum team, with the scrum master acting as a coach and facilitator |
| Key steps and outcomes | 1. Discuss the team’s work methods and efficiency
2. Identify areas for improvement The key outcome is a list of actionable items for the next sprint |
Backlog refinement, also known as backlog grooming, is an optional scrum event that helps product owners prioritize backlog items. The purpose of this meeting is to have a prioritized backlog with ready-to-develop stories.
The product owner facilitates these meetings and invites the relevant parties as needed. During backlog refinement, the product owner and some or all of the team members review the backlog items together.
In addition, the product owner can discuss the user stories to get more input from a technical perspective or about design constraints. In light of any new information, the product owner can then choose to create a new user story or update the existing user story with the relevant information.
Also on the agenda of the backlog refinement meeting is removing old, irrelevant user stories to clean up the backlog.
There is no specific schedule for backlog refinement. It can be scheduled as frequently as needed or not at all.
Each item in the product backlog gets reviewed by the group. Backlog refinement ensures that the backlog remains populated with relevant, detailed items and their priority.
Pro tip: Frequent, brief backlog refinement with the development team encourages healthy discussion and involvement from the developers, creating a more common understanding among the team regarding the user value. It also helps facilitate smoother sprint planning and reduces potential roadblocks during the sprint.
| Summary: Backlog refinement | |
|---|---|
| Definition and purpose | Prioritize backlog items with ready-to-develop items/user stories to enable smoother sprint planning |
| Duration | No set schedule |
| Participants and roles | This is an optional meeting so all relevant parties are invited but do not need to attend |
| Key steps and outcomes | Review the backlog as a group. Update existing user stories or add new ones based on the information that surfaces in this meeting |
By now, you’ve hopefully seen how these five scrum meeting types provide an efficient, structured approach to a team’s sprint execution. Here’s a summary of each ceremony:
| Meeting type | Purpose | Participants | Duration | Outcomes |
|---|---|---|---|---|
| Sprint planning | Plan, estimate, and agree upon the upcoming sprint’s deliverables | The entire scrum team, including anyone involved in building or developing the product or feature | Two hours for each week of the sprint | A common sprint goal for team members |
| Daily scrum | Share each team member’s daily progress and plans to contribute toward meeting the sprint goal | Scrum master and development team. Optionally, the product owner and other stakeholders | 15 minutes per day | Updated sprint backlog and a plan for the upcoming day’s work |
| Sprint review | Discuss and demonstrate work completed during the sprint | The entire scrum team, including any relevant stakeholders | Four hours or less | Feedback on completed work, revised product backlog, and adjusted priorities for the next sprint |
| Sprint retrospective | Reflect on and improve processes | The entire scrum team | 1–3 hours | A list of actionable items for the next sprint |
| Backlog refinement | Review the backlog and add or update user stories | Optional for all relevant parties | No set schedule | Prioritized backlog items and updated user stories |
Appreciation of agile product development is spreading throughout markets. The benefits of agile ways of working are undeniable. New frameworks are evolving to improve value and efficiency and to make it easier for organizations to transition to agile practices.
Scrum is one of the first defined product development processes. It is widely adopted by organizations transitioning to agile product development because it’s simpler and determines clear steps on the team level to facilitate a smoother evolution.
The scrum framework enhances the product mindset, which is essential for successful product delivery. The product mindset is to understand and accept accountability and responsibility for your task while enjoying autonomy and freedom in your daily work.
Scrum meetings are the cornerstone of the scrum framework. When correctly executed, they enable teams to reach their desired product goals while becoming agile. Scrum meetings are not just processes to follow; they empower the product development team to develop and deliver results quickly and allow room for learning and iteration along the way.
Featured image source: IconScout
LogRocket identifies friction points in the user experience so you can make informed decisions about product and design changes that must happen to hit your goals.
With LogRocket, you can understand the scope of the issues affecting your product and prioritize the changes that need to be made. LogRocket simplifies workflows by allowing Engineering, Product, UX, and Design teams to work from the same data as you, eliminating any confusion about what needs to be done.
Get your teams on the same page — try LogRocket today.
The following post breaks down why the feature factory mindset persists, how it manifests, and most importantly, how to escape it for good.
This article discusses where a responsibility assignment matrix, aka a RACI chart, can be helpful in product management.
Mariah Craddick shares how product management differs in the media industry and how The Atlantic is innovating with new technologies.
If you get AI personalization right, you’ll see higher customer retention, increased trust, and long-term revenue growth.
Learn more →
3 Replies to "Guide to the five types of scrum meetings"
The author seems oblivious to the fact that the 3 question agenda for the Daily Scrum was removed from the Scrum Guide in 2020.
Hi Jason,
Thank for your feedback.
The new scrum guide says that “ The Developers can select whatever structure and techniques they want, as long as their Daily Scrum focuses on progress toward the Sprint Goal and produces an actionable plan for the next day of work. This creates focus and improves self-management.”
So it’s the same idea behind but as mentioned in my article as well that it can get monotonous with the 3 questions format so instead have a dialogue about your days work. There is no where explicitly said “do not use the 3 questions format” and since this article is written based on my experience as a product owner and we in my team still find that keeping in mind these 3 questions to be useful so people don’t devolve into deeper discussions instead take it right after the daily scrum as a part of inspect and adapt mindset.
Thank you for your feedback, hope you got some value from the article.
The 3 question agenda is perhaps useful for new teams that have not yet learned to self-organize and collaborate, but it’s important to understand that it was removed from the Scrum Guide because Sutherland & Schwaber felt it placed too much onus on individual status, which reduces team collaboration. It also tends to makes the event stale and repetitive, and feel more like a status update than a mini planning session. You may find the following articles useful:
https://www.scrum.org/resources/blog/going-beyond-three-questions-daily-scrum
https://agileauthority.com/daily-standup-greatness/
Cheers
Jason