At first glance, it might seem strange that the Scrum method is the go-to for many software teams around the world. If there’s one thing that’s unanimously agreed upon across industries and departments, it’s this: Nobody likes unnecessary meetings. And the Scrum method calls for a lot of meetings. 

Here’s the thing: none of the Scrum meetings are unnecessary. As an Agile framework, Scrum relies on frequent, face-to-face communication to facilitate short working cycles. In this post, we’ll break down each type of Scrum meeting and explain why each type is indispensable to the Scrum process. 

What is Agile?

Before getting into anything else, let’s go over some background information. As mentioned above, Scrum is an Agile framework: So what exactly does that mean? 

Over the last twenty years, Agile software development has become a norm in the software engineering world. The Agile method has even been adapted for use in other industries and fields. Love it or hate it, there’s no denying one thing: Agile methodology is incredibly popular—and if you haven’t already, you should probably familiarize yourself with the basics. 

So here’s what you need to know about Agile. Though Agile is often described or understood as a method for getting things done—a step-by-step process—it’s actually a framework for thinking about and approaching your work. This framework and its guiding principles are outlined in the Manifesto for Agile Software Development. Agile isn’t a specific method, it’s an umbrella term. And under that umbrella, there are several Agile methods, including Scrum.

In traditional software development, engineering teams often seek to finish a product in one fell swoop. Here’s the problem: That one fell swoop usually takes months to complete. 

Teams using Agile methodology, on the other hand, operate in short intervals called sprints. Sprints vary in length depending on the team, but a standard sprint is two weeks long. During these sprints, teams tackle specific tasks, reflect on the process, and then seek to improve in each subsequent sprint. The goal is to first and foremost create a working product; that product is then honed and improved iteratively in future sprints. 

Types of Agile frameworks

As mentioned above, Agile software development isn’t a step-by-step method—it’s a mindset and approach. And there are numerous methods and frameworks that fall under the Agile umbrella. In this section, we’ll briefly explore two of the most prominent Agile frameworks: Scrum and Kanban.

Scrum

A defining feature of the Scrum method is its emphasis on team collaboration and decision making. Tasks and projects are broken down into two-week sprints. At the beginning of each sprint, the entire Scrum team meets together to decide what they hope to accomplish and who will be assigned which tasks. Throughout each sprint, Scrum teams continue to meet together frequently to keep things moving smoothly. 

That sprint’s tasks are then arranged on a Scrum board—this can either be a physical whiteboard or a virtual Scrum board. The board is broken into three (sometimes more) columns: To do, in progress, and completed. Tasks, represented by smaller cards, are sorted into their corresponding columns.

Kanban

Like Scrum, the Kanban method organizes tasks with cards on a board. (Again, this can be physical or virtual.) But, for the most part, that’s where the similarities end. 

In the Kanban method, there’s no time limit. The backlog is constantly updated—once a task is begun, its card is moved into the “in progress” column, and so on through the corresponding columns until it is completed.

The goal of the Kanban method is to help teams organize their workflow and eliminate bottlenecks. To do this, teams decide on a strict work-in-progress limit. The WIP limit defines the number of tasks that can be in any given column on the Kanban board. This helps reduce multi tasking, keeping team members focused and efficient. 

What are the five key Agile Scrum meetings?

If you're using Scrum, the course of each sprint, your team should hold five types of Agile Scrum meetings. But don’t worry, most only occur once per sprint. In the following section, we’ve explained the basics of each meeting: When should it occur? Who should attend? And what does the meeting accomplish? Armed with this info, you’ll be ready to run smooth and effective sprints in no time!

Sprint planning meeting

Before your team begins a Scrum sprint, you need to know where you’re going. This is where the sprint planning meeting comes in. A sprint planning meeting should be one of the longest Scrum meetings you hold—plan on two hours of planning for each week of your sprint. (A two-week sprint, for example, requires roughly a four-hour planning meeting.) While this may seem like a lot, remember that you only need to hold one sprint planning meeting per sprint—right at the start. 

The purpose of a sprint planning meeting is simple: Establish what you and your Scrum team want to accomplish this sprint and evaluate the bandwidth you have available. From there, you can plan the sprint, assign tasks, and set deadlines. Make sure each team member understands the ins and outs of the tasks they are assigned. You’ll want to invite the product owner to this meeting so they can clear up any ambiguities and help establish expectations.

To host an effective sprint planning meeting, check out our guide to sprint planning.

Daily standup meeting

As the most frequently held Agile Scrum meetings, daily standup meetings are the bread and butter of Scrum sprints. They’re short, to the point, and, as the name suggests, held each day—they’re typically the first meeting of the work day. By the end of a standup meeting, each team member should have answered two questions: What did I accomplish yesterday? And what am I going to accomplish today? Standup meetings are also a time for team members to bring up any roadblocks they are facing. 

Though daily standup meetings only take between fifteen and thirty minutes, they are an effective way to keep each team member up-to-speed, on task, and openly communicating with others. Because they are held so frequently, standup meetings also allow teams to address problems as they arise, keeping the sprint moving on schedule.  

Here's a quick course to help you set up and implement a daily stand-up for your team!

Sprint review meeting

Sprint review meetings are held at the end of each sprint. This meeting is an opportunity for you and your team to demonstrate what you’ve accomplished to the product owner and other stakeholders outside of your team. 

Your goal in a sprint review meeting is to gather feedback. As you demonstrate new product features and functionality, allow the product owner and other stakeholders to respond to and evaluate your work. Agile methodology relies on open and frequent conversations: As you and your team document, respond to, and act on feedback, remember that these conversations help create a better product. 

Certain feedback points may require additional work on the product—add them to your backlog and consider including them in the next sprint. This is a matter of priority: While you should implement the feedback eventually, if other tasks are more pressing you can save it for a sprint down the road.

Host a successful sprint review in Lucidspark with this quick course.

Sprint retrospective meeting

Just like review meetings, a sprint retrospective meeting is held at the end of each sprint. Whereas review meetings include the product owner and other stakeholders, retrospective meetings are primarily for the benefit of your Scrum team—there’s usually no need to get outside players involved.

During a sprint retrospective meeting, address these questions with your Scrum team: What went right this sprint? What went wrong? And what could we do differently next time?

These meetings don’t have to be long (usually somewhere between one and two hours), but they allow teams to constantly improve.

Use this guide to set up and facilitate an effective sprint retrospective for your team.

Product backlog refinement

Product backlog refinement meetings occur between sprints (usually just once per interim, but you could always schedule another if needed). If you’re anything like us, your backlog tasks are likely a bit rough around the edges. And that’s ok! This meeting is your chance to add clarifying details, establish deliverables, and prioritize the tasks in your backlog. 

A thorough product backlog refinement meeting makes your life easier. Remember the oh so long sprint planning meeting you held at the beginning of the sprint? If you take the time to refine your backlog, sprint planning is a quicker and smoother process.

Take our product backlog refinement course to learn how to facilitate a successful setup and implementation. 

Tips for organizing Agile Scrum meetings

At this point you’ve probably realized something: the Scrum method relies on face-to-face meetings. Without them, a sprint will derail and fall apart. But face-to-face doesn’t necessarily mean in person. And whether your team is working remotely or in the same building, a virtual Scrum board can help keep meetings organized and team members informed. Enter Lucidspark. 

With Lucidspark, you can create virtual Scrum boards, share them with your team, and collaborate in real time. And that’s not even the best part! We’ve highlighted three Lucidspark features you can use to organize your Agile Scrum meetings:

1. Timer: It’s easy for team members to get frustrated with the sheer number of Scrum meetings they need to attend—especially if those meetings routinely run long. When you pull up your Scrum board in daily standup meetings, use Lucidspark’s internal timer to ensure you wrap up on time.
2. Color coding and tags: Your Scrum board is a powerful visual resource for your team throughout each sprint—so long as it’s organized. To add clarity, try using Collaborator Colors and tags to identify which tasks belong to which individuals. 
3. Linking: You don’t want to clutter your Scrum board with unnecessary information. Remember: Not every team member needs the details for every task. Add links to external documents, other Lucidspark boards, or Lucidchart documents to give team members access to any additional documentation they might need.