How to Run Scrum Meetings

Beginner’s Guide

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?

Introducing Scrum

For more than a decade, companies have adopted the SCRUM approach and its principles. Since then, interest in adopting it by other companies has constantly been on the rise.

And for good reasons too!

Scrum Interest Over Time

Scrum Guide defines scrum as a framework that helps teams deliver even complex products quicker and with fine quality. Scrum is lightweight and easy to understand that help teams set expectations, collaborate effectively, and ultimately drive results.

Seriously, which product manager doesn’t want that?

If you ever find people around you sit through multiple meetings, use words like sprints, backlogs, and burndown charts, you can be sure they follow scrum principles among their team.

“Multiple meetings? Aren’t meetings a productivity killer?”, I hear you say.

Meetings, in the last five years have been projected as the villain who is out to kill everyone’s productivity.

But the truth is far from it.

A study by Steven Rogelberg and his colleagues from the University of North Carolina found employees spend increasing amounts of time in meetings and love to complain about them. But privately they see meetings as a productivity tool — one that companies can learn to use better.

When asked to rate meetings in terms of productivity, 42% of the people who attended meetings rated it as good ; and 17% found meetings to be either very good or excellent.

Successful organizations do not treat meetings as a necessary evil. Instead, they view them as a strategic resource and seek out ways to get the most from them.

~ Steven G. Rogelberg, Cliff Scott & John Kello

But that doesn’t mean you should sit through meetings that last for an entire day.When you run meetings that are structured, time-boxed, and have a purpose, they can be your best friend.

In this blog post, we’ll see what scrum meetings are, their types, and few best practices so you can get maximum value out of them.

Before we jump in, let’s take a look at some of the common terminologies and people roles you’ll come across.

Basic Scrum Terminologies

1. Product Backlog

The product backlog is a list of everything from features, enhancements, user requirements, and bug fixes needed to build a complete product.

A product backlog is never complete and is always evolving as you and your team gather new information about your user’s needs and your product’s market.

2. Sprint

A sprint is a collection of items from the backlog that is time-boxed to a month (or lesser) with the goal of shipping a useable, incremental version of the product.

Basic Roles In Scrum

When a company decides to use Scrum, one of the first things to understand is how Scrum roles differ from traditional project management roles. While there are only three main roles in Scrum, they don’t automatically align with titles familiar to most of us.

Three scrum roles

1. The Development Team

The development team is a cross-functional team of developers, QA testers, designers, and other technical members who are needed in the actual development of the product.

2. Product Owner

The product owner owns the backlog, strives to prioritize, and takes all the key decisions with respect to the product. This person turns all the user stories into chunks of work so the development team can work on them.

Related Read: Learn how to write great user stories. Templates and examples included_Write great user stories to help your team ship quality features. Follow this guide for best practices, tips, and templates._blog.zepel.io

3. Scrum Master

The scrum master is responsible for making sure the entire team has everything they need to build and ship a task or user story on time. This person often communicates progress and ensures there aren’t any roadblocks.

So, what are the different types of scrum meetings?

There are four types of Scum meetings:

1. Sprint Planning
2. Daily Scrum
3. Sprint Review
4. 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 a meeting, 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

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 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:

1. Sprint goal — Agree on what will be delivered at the end of the sprint
2. 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, the 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 the 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

Summary of Sprint Planning Meeting

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 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:

1. What did I do yesterday that helped the Development Team meet the Sprint Goal?
2. What will I do today to help the Development Team meet the Sprint Goal?
3. 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 the 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.

Summary of Daily Scrum Meetings

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 the 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 an effective 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.

Summary of Sprint Review Meeting

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 next sprint’s 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:

1. Inspect how the previous sprint went with respect to people, relationships, tools, and processes.
2. Identify items that went well and see where there is room for improvement.
3. 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 an effective sprint retrospective meeting

1. Take small but concrete steps: Making improvements require teams to make changes. And the thing about changes 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.

Summary of Sprint Retrospective Meeting

Conclusion

In the last five years, nearly every team we spoke to, jumped on the bandwagon to use tools like Slack to communicate with their team. They’re great if you want to ask your teammate for more information about a task or request for a report.

But when it comes to collectively deciding what your team is going to ship in the next sprint, or getting them motivated and pumped up to hit an important deadline, communication tools just cry.

While meetings can be bad for your team if they aren’t structured and time-boxed, they can be your best friend when the best practices are followed and tweaked to your team’s needs.

And scrum meetings let you do just that.

If your team is new to scrum, scrum meetings, and running sprints, this guide hopefully gave you enough information, so you can kickstart a new sprint within your team in a jiffy.

Zepel.io is the project management tool for software teams to manage backlog, collaborate, and ship features on time. Drop us a line in the comments or shoot an email to [email protected] with your thoughts and suggestions.

Originally published at blog.zepel.io on December 12, 2018.