Scrum Ceremonies or Meetings
Questioning the importance of a meeting isn’t new.
There are creatives - designers, marketers, and developers - who cringe at the thought of attending a meeting. And then, there are product managers, engineering leaders, and executives who see value in attending several meetings every day.
To be fair, both camps have some rather compelling points.
Run meetings for the sake of it, you risk frustrating your team. From unplanned agendas to “why am I in this meeting?” and everything in between, you’ve heard them all… And it only gets worse with every new meeting as productivity starts to drop.
Banish meetings altogether, you’ll end up with a team optimizing on low-value bugs when you’ve got important features prioritized.
If you have perfect people and they are perfectly misaligned, the result is zero progress. ~ Dharmesh Shah, Founder at Hubspot
So, how do you run meetings that brings your team together and doesn’t bore them to death?
TOPICS COVERED IN THIS GUIDE:
- Types of Scrum Meetings
- Sprint Planning Meeting
- Daily Scrum Meeting
- Sprint Review Meeting
- Sprint Retrospective Meeting
Types of Scrum Meetings
There are four types of scrum meetings:
- Sprint Planning
- Daily Scrum
- Sprint Review
- Sprint Retrospective
The good news is, most teams follow a variation of these meetings already. Unfortunately, they are neither structured nor productive.
The internet is overflowing with blog posts that cover the basics from why you should send an agenda before meetings, to how to conclude a meeting on time.
But the key to getting maximum bang out of each scrum meeting isn’t just about sending the agenda before the meeting and sticking to time.
With each scrum meeting focussed on achieving a specific goal, everything from who attends it to best practices will vary.
So, how do you make each of your scrum meetings productive, effective, and efficient?
Let’s jump in and find out.
Sprint Planning Meeting
What is a Sprint Planning Meeting?
A sprint planning meeting is where teams come together, discuss, and agree on what they’ll deliver in the upcoming sprint.
During the meeting, the product owner explains the highest priorities, helps the development team understand why the user stories are important, and how they’ll impact their users. With this knowledge, the development team asks questions to get a better understanding, and try to break down the user story into actionable pieces of work with an estimate on how long it’d take to build it.
In short, the main goal of the sprint planning meeting is to walk away with two things:
Sprint goal: Agree on what will be delivered at the end of the sprint.
Sprint backlog: A prioritized set of user stories, tasks, and sub-tasks that will help the team focus and deliver by the end of the sprint.
Who should attend a Sprint Planning Meeting?
All members of the sprint - the development team, the product owner, and the scrum master - should attend the sprint planning meeting.
When you’re discussing to agree on what everyone will deliver at the end of the sprint, it’s best to get everyone’s input and perspective before you move forward. After all, you wouldn’t want to miss any edge cases.
How long should a Sprint Planning Meeting last?
According to Scrum Guide, the sprint planning meeting is time-boxed to eight hours for a one month sprint. If your sprint is shorter than a month, sprint planning meeting is reduced proportionately. For example, a two-week sprint should not have a sprint planning meeting that exceeds four hours.
But does that mean you must spend eight hours planning for a month-long sprint?
If a meeting concludes before the time allotted, end the meeting and leave! Don’t try to fill the time with other random top of mind topics. ~ Paul Adams, VP of Product at Intercom
As long as your team is on the same page on what will be delivered in the upcoming sprint, it’s alright if your meeting ends in an hour. Remember, principles support your business. You shouldn’t mould your business around them.
Best practices on how to run an effective Sprint Planning Meeting
1. Have a groomed backlog:
Before the sprint planning meeting, make sure the backlog is groomed with fully formed user stories and the most important work listed at the top. It’s best done a few days before the sprint planning meeting with just the product owner and the scrum master.
This allows the product owner and scrum master to fill details and context to user stories that might not be fully formed and come prepared for the sprint planning meeting.
2. Tell a story:
As a product owner keeping in mind that each backlog item is a user story and not a bunch of features could make a world of difference, especially when you’re trying to explain it to your development team.
Showing your dev team where the problem occurs in the user’s current solution and why it’s a pain will help them get a clear picture of what they need to be working on.
After all, the sprint planning meeting is a way for the product owner to convince the rest of the team on what the highest priorities are. And what better way to convince people than telling a story?
3. Drill down to the details:
When you drill down to the details of a user story by breaking it down to tasks and subtasks, the entire team gets an idea of the complexity involved in building it. Besides, breaking down a large chunk of work into tiny pieces of actionable work makes estimating accurately easier.
When you haven’t thought about what you’re going to do, you can’t know how long it will take. ~ Joel Spolsky, CEO of Stack Overflow
Daily Scrum Meeting
What’s a Daily Scrum Meeting?
The daily scrum meeting (or daily standup meeting) is the most common type of meeting that most teams already follow. As the name suggests, this meeting is held every day during a sprint.
A daily standup meeting is not a status meeting, but a meeting that reveals roadblocks and gives the team a chance to solve them before it’s too late.
The main goal of this meeting is to share with the rest of the team the progress made towards the sprint goal (that was decided during the sprint planning meeting) and identify possible roadblocks.
How does a standup meeting reveal roadblocks? Glad you asked. During the standup meeting, each member of the development team take turns to answer:
- What did I do yesterday that helped the Development Team meet the Sprint Goal?
- What will I do today to help the Development Team meet the Sprint Goal?
- Do I see any roadblocks that prevent me or the Development Team from meeting the Sprint Goal?
Answering these questions help teams get an understanding of who’s working on what and reveal if someone is unable to make progress on the task assigned to them.
Who should attend a Daily Scrum Meeting?
The daily scrum meeting is for the development team and the scrum master. The product owner and other stakeholders can be present when there’s a need or a dependency.
How long should a Daily Scrum Meeting last?
Unlike other scrum meetings, the daily scrum meeting is the shortest. This meeting shouldn’t last more than 15 minutes and the scrum master’s role is to ensure that it stays that way.
Best practices on how to run an effective Daily Scrum Meeting
1. Keep it conversational:
The thing with daily standup meetings is, it can quickly become robotic when you’re trying to answer the three questions. Even worse, it could sound like an interrogation if there’s someone asking the question and you’re answering to them.
Share updates like you would when you’re talking about an interesting tech you found during a coffee break - conversational and friendly.
2. It’s the development team’s meeting:
While other members can be present in the meeting, the daily scrum meeting is for the development team. The role of a scrum master during this meeting is to ensure other members do not disrupt the meeting and keep the meeting within the 15-minute time box.
3. Resolve roadblocks after the meeting:
During the meeting when you identify concerns, it’s easy to want to jump head first and try to solve them. But that will only end up prolonging your standup meeting.
When you identify possible roadblocks be sure to note it down separately. At the end of the meeting, meet up with the individual who is blocked and discuss in detail about the problem at hand to find solutions, adapt or replan.
Sprint Review Meeting
What is a Sprint Review Meeting?
During the sprint review meeting, the development team takes the spotlight to show all the work completed during the sprint. This meeting gives all the other stakeholders a chance to see the feature so they can inspect and ask questions.
Think of sprint review meeting as a casual demo Friday, where you demo your finished feature/product to people and answer questions. However, depending on how your company is set up, this meeting could also be more formal with the product owner explaining what tasks in the sprint where completed (and what weren’t) while the development team showcases them.
The goal of the sprint review meeting is to get feedback on the completed items and have a product backlog that is revised enough to make it a probable backlog for the next sprint.
Who should attend a Sprint Review Meeting?
The product owner, scrum master, and the development team are the folks who must attend a sprint review meeting. However, other key stakeholders such as clients/beta customers, members of the sales team, and other business executives could attend this meeting.
How long should a Sprint Review Meeting last?
Since this meeting is designed to showcase a finished feature and elicit feedback, this meeting shouldn’t last for more than an hour for a one week sprint.
That means, if your sprint is four weeks long, the sprint review meeting shouldn’t last longer than four hours.
Best practices on how to run a Sprint Review Meeting
1. Focus on the goal, not the number of tasks:
Let’s be honest… Your team almost always has a few tasks in the sprint that remain incomplete. They are after all humans too.
During the sprint review meeting, the focus should be to see if the overall sprint goal (that was decided during the sprint planning meeting) is met and not how many tasks were checked off.
2. Gather feedback:
Giving a demo to people who have zero (or partial) context of what you’ve built is the easiest way to get actionable feedback.
During the meeting, the product owner should take ownership of asking questions and gathering feedback that can be used in future sprints.
Sprint Retrospective Meeting
What is a Sprint Retrospective Meeting?
The sprint retrospective meeting is for the development team to look back at the sprint, inspect itself, and plan for improvements that can be used for future sprints.
This meeting is held after the sprint review but before the beginning of the next sprint planning meeting. By the end of the sprint retrospective meeting, the development team should have identified improvements that can be implemented in the next sprint.
The purpose of this meeting is to:
- Inspect how the previous sprint went with respect to people, relationships, tools, and processes.
- Identify items that went well and see where there is room for improvement.
- Build a plan on how to implement improvements to the way development team works.
Who should attend the Sprint Retrospective Meeting?
The scrum master and the development team collaborate in this meeting and try to find areas that could be improved.
The product owner is an optional attendee with no other stakeholders attending this meeting.
How long should a Sprint Retrospective Meeting last?
The sprint retrospective meeting lasts for a maximum of three hours for a one month sprint. For shorter sprints, this meeting is usually shorter.
Best practices on how to run a Sprint Retrospective Meeting
1. Take small but concrete steps:
Making improvements require teams to make changes. And the thing about change is it’s always hard, especially when it’s for something good.
Look for small, incremental improvements that can be adopted by teams quickly.
2. Keep the tone positive:
When inspecting on areas to improve, it can be easy to start pointing fingers by focusing on the negatives and why they shouldn’t have come up in the first place.
By focusing on the positive aspects of what went well in the previous sprint and stating that it could be improved, you help set a positive tone for the entire meeting and avoid a possibly productive meeting turn into a rant session.