According to The Scrum Guide, scrum is defined as a framework that allows teams to deliver complex products and features quickly and efficiently. However, common scrum meetings regularly fill up your calendar regardless of the organization’s framework and methodology.
In this guide, we’ll introduce you to the general concept of scrum and zoom in on each of the five types of scrum meetings in greater detail.
The five types of scrum meetings are:
- Sprint planning
- Daily scrum
- Sprint review
- Sprint retrospective
- Backlog refinement
Table of contents
What is a scrum meeting?
The term scrum meeting describes all regular meetings held by scrum teams 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.
What are sprints?
To better understand the purpose of scrum meetings, it is first essential to understand what sprints are.
According to The Scrum Guide, a typical development cycle is for two to three weeks or a month. This period of development is called a sprint or iteration. It’s short and mainly focuses on quick, incremental delivery, with faster learning and iteration instead of long, full-scale product development and delivery.
The purpose of following scrum and sprints is to eliminate any blindsides and avoid undertaking features that may not serve the best interest of end users. Therefore, scrum meetings are specific meetings that are regularly held to plan and run sprints.
What are the five meetings in scrum?
As mentioned above, scrum consists of five ceremonies 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.
1. Sprint planning
A sprint planning meeting is a session for team members to plan the work for the upcoming 2–3 weeks. Sprint planning meetings are usually full-day events for a month’s sprints but can be proportionately shorter for shorter sprints managed by a scrum master.
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.
A common example of 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 is important to note that these estimation points do not 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 starts.
The goal of the sprint is to produce and deliver value for the end user; it is not a sprint goal to complete all tasks in the sprint.
Learn more →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.
In summary
- The purpose of sprint planning is to plan, estimate, and agree upon the deliverables of the upcoming sprint
- A typical sprint meeting agenda is to go through the user stories from the prioritized backlog, create tasks and subtasks, estimate the user story, pull the agreed-upon number of stories into the sprint, set a sprint goal, and start the sprint
- The participants of a sprint meeting are 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
- The desired outcome of sprint planning is to establish a common sprint goal that is collaboratively decided upon by team members based on priorities, team velocity, and value realization to the end user
2. Daily scrum
The daily scrum is a 15-minute time-boxed meeting to update on progress and set the day’s goal.
The goal of the daily scrum, also called the daily standup, is to share the progress that each team member has 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 the team from achieving its daily objective.
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:
- What did I do yesterday that contributed to the sprint goal?
- What will I do today to contribute to the sprint goal?
- Are there any roadblocks that will impede my or my team’s development work?
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.
The daily standup is organized and monitored by the scrum master. It is 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.
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 present your answers as a dialogue instead of simply listing off updates.
In summary
- The daily scrum is a 15-minute sync meeting between the scrum master and development team that occurs every day
- The goal is to give progress updates and highlight any roadblocks that could set back the development task
3. Sprint review
The sprint review is a meeting in which the development team highlights the work it has done during the sprint, demos it for stakeholders, and addresses any questions they may have while inspecting the development.
During the sprint review, the development team highlights the work it completed during the sprint. Usually, the team also presents a live demo of the feature to the stakeholders. The demo provides a chance for stakeholders to see the feature in action for the first time and inspect it. 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.
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 of the meeting. Below is an example of a sprint review meeting agenda that you can reference when planning your own meetings. 
The sprint review is the second-to-last event of the sprint. It is time-boxed to a maximum of four hours for a one month sprint, though it is usually shorter for shorter sprints.
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.
Subscribe to our product management newsletter
Get articles like this to your inbox
In addition, 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.
In summary
- In the sprint review, the scrum team explains which user story items have been “done” and which have not been “done”
- The development team discusses what went well during the sprint, what problems they ran into, and their solution implementation
- Developers demonstrate their work and answer stakeholders’ questions
- The product owner discusses the product backlog as it stands. They also discuss the project’s likely target and delivery dates based on progress
- The entire group collaborates on what to do next so that the sprint review provides valuable input to subsequent sprint planning
- The outcome of the sprint review is a revised product backlog that defines the probable product backlog items for the next sprint. The product owner may also adjust the overall backlog to meet new opportunities
4. Sprint retrospective
The sprint retrospective is held at the end of a sprint to evaluate what went well and reflect on anything that must be improved upon in the next sprint for more efficient delivery.
The primary purpose of the sprint retrospective is to take stock of how the recent sprint went in terms of processes followed, people involved, tools used, collaboration, and relationships. Based on this reflection, the team combines a list of things that went well during the sprint with a list of things that didn’t go well and a list of potential improvements.
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 — that includes 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, respective to 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.
In summary
- The goal of a sprint retrospective is to reflect on and improve processes
- The entire scrum team must participate in the sprint retrospective. The scrum master acts as a coach and facilitator
- A sprint retrospective agenda can include anything that might improve the development team’s work methods and efficiency
- The desired outcome of a retrospective is a list of actionable items for improvement in the next sprint
5. Backlog refinement
Backlog refinement, also known as backlog grooming, is an optional scrum event that helps product owners prioritize backlog items and detail stories to prepare for development.
During backlog refinement, the product owner and some or all of the team members review the backlog items together. The purpose of this meeting is to have a prioritized backlog with ready-to-develop stories.
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. The product owner facilitates these meetings and invites the relevant parties as needed. 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 more common understanding among the team regarding the user value. It also helps facilitate smoother sprint planning and reduces potential roadblocks during the sprint.
In summary
- Backlog refinement is not a regular scrum event but can be organized as required by the product owner
- Backlog refinement ensures prioritized, ready-to-develop items/user stories to enable smoother sprint planning
Conclusion
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.
LogRocket generates product insights that lead to meaningful action
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 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 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