
5 types of scrum meetings
(with best practices + templates)
1. Sprint planning meeting
The sprint planning meeting happens at the beginning of your sprint, which is usually two
weeks long. The purpose of the meeting is for your team to decide which user stories
(features) from your product backlog to tackle so you can achieve your sprint goal.
During the meeting, the product owner gathers the entire scrum team to explain how the team
should complete each step of the project. Scrum team members discuss what can be
realistically completed during the time frame of the sprint.
Sprint meetings last two hours for each week of the upcoming sprint. So, if your sprint is
two weeks, your meeting will be four hours long. At the end of the session, everyone should
know their tasks, responsibilities, and deadlines.
The sprint planning session ends with a sprint backlog (your team's tasks) and a sprint
goal. A sprint goal is a statement that outlines the main objective of the sprint.
2. Daily scrum / daily stand-up meeting
Daily standups are meetings you'll be holding each day of the sprint.
A daily standup or a daily scrum meeting lasts for about 15 minutes at the start of each
day. The strict time-boxing is meant to keep the meeting light, quick, and focused.
The objective is for each team member to give a quick status update or flag a roadblock.
There are three main questions that every team member answers during the meeting:
- What did you do yesterday?
- What are you working on today?
- Are there any impediments?
Despite the simplicity, these three questions tell product owners a lot about the status of the sprint and whether tasks are progressing as expected. The ritual also fosters teamwork and open communication among all team members.
3. Sprint review meeting
The sprint review meeting happens at the end of your two-week sprint. This is when the
product development team shows off their deliverables to the product owner, scrum master,
and other relevant stakeholders.
Also known as a product demo, the meeting is a chance to demonstrate the functionality of
the product at the end of each sprint. Since the scrum process relies on frequent and honest
conversations to make the product better, this is when the team gets feedback based on the
sprint goal.
Some feedback may require additional work. These tasks should be added to the product
backlog for possible inclusion in the next sprint.
4. Sprint retrospective meeting
A sprint retrospective also happens at the end of the sprint, but its objectives are a
bit
different from the sprint review.
During a sprint review, the product owner and other product stakeholders review and
assess
the results. During a retrospective, the review focuses on the scrum team itself.
The main questions to ask at a sprint retro are:
- What went right?
- What went wrong?
- What can we do differently during the next sprint?
This meeting should be long enough for productive discussion to take place but not so
long as to burden the team. An hour or two should be enough. And unlike the sprint
review, there's no need to involve anyone but the scrum team members.
Even if the sprint went generally well, there's still room to reflect on the process.
Continuous improvement is the name of the game in agile methodology, so don't rest on
your laurels.
That said, the discussion should be friendly, impartial, and non-judgmental. The scrum
master or the meeting facilitator needs to make this point clear to avoid negativity.
5. Backlog refinement meeting
The backlog refinement meeting is the final ceremony in the scrum process. During this
meeting, the team analyzes and refines the product backlog items in preparation for the next
sprint planning meeting.
These items, often written as user stories, need to be refined before they can be included
in the next sprint's backlog. During this meeting, the team will have a technical discussion
with the product owner to ensure that everyone is on the same page about the deliverables
and their requirements.
While having another meeting may seem unnecessary, it's important to note that the better
the backlog is refined, the easier the next sprint planning meeting will be. In reality,
backlog refinement should be an ongoing process and not just a time-boxed event. This means
that the team doesn't need to wait until the end of the sprint to refine the backlog if they
feel like they need to.
It's worth noting that the backlog refinement meeting used to be called “product backlog
grooming”, so if you come across that term, now you'll know what it means.