Does Scrum Have Too Many Meetings?

A common criticism of Scrum is that it has too many meetings or that the meetings take too long and distract from “real work.”

However, when a team complains about Scrum meetings, it’s usually not truly a case of too many meetings in Scrum. Instead, these complaints are typically symptoms of one of two potential root causes.

1. The meetings themselves aren’t understood or working as intended, or
2. The team hasn’t yet bought into an agile way of working (or has some baggage from flawed implementations of agile in the past).

I’ll talk about the easy fix first: the meetings themselves (aka Scrum events or Scrum activities). Then I’ll address the deeper concerns that might be hiding behind complaints of too many meetings or too much overhead.&

The Myth of Scrum Overhead

I empathize with people who complain about meeting overhead. I hate meetings, too. Actually, I hate unnecessary or overly long meetings.

That being said, I’m skeptical of the ability of a team to consistently deliver valuable products with much less overhead than Scrum. Scrum requires only a single fifteen-minute meeting each day plus a half- to full-day at the start and finish of a sprint. There just isn’t much that you could cut out of Scrum in order to reduce overhead.

Are There Really Too Many Meetings in Scrum?

Still think Scrum has too many meetings? Try this experiment.

Pick a random number from 5–10. Then think back to when your team first began working in an agile way or perhaps when they first started to get good at it.

Go to that month on your work calendar. Now, remember the random number you picked in the previous paragraph? Back up the number of months that corresponds to your random number.

So, for example, suppose your team started to get the hang of agile in October and you picked 5. In that case you’d back up five months from October and look at May.

Next, look through that month, making note of all meetings you had during the month. You probably had occasional meetings with stakeholders. You had the weekly update with your boss. You might have been on a couple of task forces. Then there were design reviews—whether user interface, technical, database, or other.

You might have had a weekly status meeting. Perhaps there were code inspections or reviews. There were one-off design discussions at the whiteboard. Add a couple of conference calls.

About half the people with whom I’ve done this in-person find that they had more meetings before starting Scrum than after—they were just different meetings. Those most likely to have had more meetings pre-agile are team members who need to coordinate their work with others.

Why It May Feel Like Scrum Has Too Many Meetings

So why is the feeling that Scrum has too many meetings so prevalent? It might be because the meetings have names and recurring space on our calendars.

Many of the meetings on your calendar pre-Scrum did not have names and did not recur regularly. They were more like “Discuss design with Mary,” “Code review with Ashish,” or “Janet - test cases.”

When we give something a name, it can become a target for criticism. People will complain about “those darn sprint planning meetings” and that “pesky daily scrum.” (They may use more colorful language.)

Why Do Scrum Meetings Exist?

To me, the meetings and the other rules of Scrum are like the lines painted on the highway. They’re boundaries that exist to enable us to go faster.

Each meeting should feel like it was held

• at the right time
• for the right length
• with the right people
• for the right reason
• and at the right level of detail

When Scrum meetings follow these rules, they help a Scrum team go faster. Meetings become an investment in sprint success rather than a burden.

The Scrum framework is designed to make this possible. If a team doesn’t feel this way about its meetings, the Scrum Master should look carefully at two things:

• Does the team understand the purpose of each meeting?
• Is the team achieving the purpose of the meeting inside the intended timebox?

To gauge the answer to these two questions, I will review the purpose and timebox of each meeting in the Scrum framework. (You can watch the video if you’d prefer.)

Sprint Planning Purpose and Timebox

We’ll start with sprint planning. The purpose of sprint planning is to establish the sprint goal and choose the relevant product backlog items the team will tackle.

To do this, teams typically discuss tasks and a rough estimate for each to form the sprint backlog. While these discussions are helpful, they should last only long enough to help choose the appropriate work.

The Scrum Master can play a pivotal role in curbing excessive debates over specific estimates; for instance, whether a task is estimated at 4 hours or 8 hours is unlikely to change a team’s decision about whether the product backlog item can fit in the sprint.

Likewise, if the developers agree that a task will take 6 hours but can’t agree on how they’ll implement it—good enough. That detail doesn’t need to be resolved in sprint planning.

What I do in this case is add a sprint backlog item saying to do the thing, give it an estimate of 6 hours, and add another task called “fight over how to do it,” and give that an hour. OK, maybe argue is better than fight—but you get my point that the debate can happen later.

I recommend that you try to finish sprint planning in 45 minutes or less per week of sprint duration. That means 90 minutes for a two-week sprint. It may take longer as a new team gets the hang of sprint planning.

You can probably do it a little faster, but don’t rush sprint planning. Saving time here is a false economy because it just means the team has left too much unidentified work that they’ll uncover during the sprint.

Sprint Review Purpose and Timebox

On to the sprint review. The purpose of the sprint review is to solicit feedback on items completed during the sprint and to discuss how that affects future plans for the product.

A demo is the central activity in most sprint reviews. A common mistake in sprint reviews is teams feeling the necessity to demo everything they worked on. Teams doing this seem to think the review is used to justify their existence.

Some items don’t warrant a demo. For example, if a team fixed a bug and fixed it in the only way it could have been fixed, it does not need to be shown. Of course you’ll show it if a review participant asks to see it.

Save time in reviews by showing just the important new functionality.

A sprint review should never take more than 90 minutes. If a lot of hot issues unexpectedly arise and the meeting is on pace to take longer than that, the Scrum Master should limit conversations and promise to schedule follow-up meetings on specific topics. Each of those meetings can be limited to the smallest set of participants necessary.

I think most sprint reviews can be completed very easily within 60 minutes. If yours are routinely taking longer, here are a few suggestions:

• Reduce the number of participants in the meeting
• Shorten your sprints
• Conduct more ad hoc demos of functionality during the sprint, solely to the most interested or vocal participants

Sprint Retrospective Purpose and Timebox

Let’s move on to the sprint retrospective.

The purpose of the retrospective is for team members to identify ways in which the team can improve.

The most common mistake in the retrospective is discussing things the team either cannot change or does not plan to change in the near term.

I once participated in a retrospective in which someone said the team should stop climate change. He didn’t want to slow climate change by perhaps reducing the team’s carbon footprint; he wanted to stop it. I’m sure the Scrum Master got right to work on that, probably after ending world hunger.

That’s an extreme example. More common is the same issue being brought up repeatedly.

One team had grand plans to simplify the creation of new automated tests with a new database of canonical test data. While the entire team supported the initiative, they collectively acknowledged that there wouldn’t be time to implement it for another six months. Despite this consensus, one team member persisted in bringing up this idea at every retrospective.

In such instances, the Scrum Master should guide team members to concentrate exclusively on issues they can influence and are eager to tackle in the short term. If the team decides to postpone a topic, the Scrum Master can set a reminder in their to-do list or calendar app, ensuring it resurfaces at an appropriate time.

If a team is new, and therefore has lots of room for improvement, I set a one-hour limit for retrospectives regardless of sprint length. I consider this a very soft limit. If a hot issue blows up and it’s worth talking about, I’m willing to let the retrospective go on as long as the conversation seems constructive.

Once a team gets good, I target 30 minutes for retrospectives. That might be a little tight and I’m occasionally told it should be longer. It’s worth keeping in mind the ROI of a retrospective. An extra 30 minutes for an 8-person team is 4 hours spent. To be worthwhile, the 30 minutes should have an improvement worth at least that to the team.

Backlog Refinement Purpose and Timebox

Now we’ll consider product backlog refinement.

The purpose of backlog refinement is to make sure the highest priority product backlog items are sufficiently well understood and small enough that each could be worked on in the coming sprint.

This is the meeting where I see the most time added beyond what’s strictly necessary. Often team members erroneously use the refinement meeting to eliminate all (or nearly all) uncertainty from each product backlog item.

Instead, you need merely to eliminate enough uncertainty that team members feel comfortable—not necessarily 100% confident—that they know enough about the backlog item to complete it in the sprint.

Scrum Masters need to help the team become comfortable bringing items into a sprint with some issues unresolved.

I recommend easing a team into this. Begin during refinement by gaining agreement that some trivial issues can remain open, but emphasize that team members can resolve them as early into the sprint as they want.

Progress from there to leaving bigger issues open to resolve during the sprint.

It’s hard to recommend a maximum amount of time for refinement because it depends on a lot of factors: how long your sprints are, how fast the team is progressing through backlog items, how messy the product backlog is currently, the domain, and more.

Independent of the length of your sprints, I recommend that you limit backlog refinement meetings to 90 minutes. If necessary, do two meetings per sprint.

For nearly all teams, I think completing refinement is very achievable in one meeting no longer than 90 minutes. It helps if you think of the meeting as a pre-planning checkpoint. You want to see if top priority items are small enough and sufficiently well understood to be done in the coming sprint. To do that, you don’t need to resolve all open issues.

Daily Scrum Purpose and Timebox

Daily scrums are a common source of complaint because, well, they happen daily.

The purpose of the daily scrum is discussing progress toward the sprint goal, adjusting the sprint backlog as needed. Team members synchronize effort during the daily scrum.

Why do daily scrums take too long? It’s often because team members spend too long discussing how to solve problems. Problems should be identified during the daily scrum, but they do not necessarily need to be resolved.

Some problems are so simple they should be addressed right when they’re brought up. I coach Scrum Masters to encourage a problem / solution / thank-you approach. A problem can be mentioned. When possible, someone provides a simple answer and is thanked.

If this turns into questions, clarifications, and additional detail, the Scrum Master intervenes and indicates the problem should be discussed by just the parties involved and immediately after the daily scrum.

I think a good target for daily scrums is about 10 minutes. This, of course, depends on the team size and more, but 10 minutes is enough to quickly synchronize effort.

I don’t recommend being one of the teams who brag about doing their daily scrums in five minutes. A five-minute is probably not worth doing.

And I’m not a huge stickler on the 15-minute limit of a daily scrum. I don’t think a team should exceed that on a routine basis, but an 18- or 20-minute daily scrum once a sprint is hardly a problem if the extra time is for a discussion that will save time later.

Scrum meetings should not be a burden. When done well, the meetings will help team members work efficiently and effectively to achieve their goals.

Complaints May Disguise Deeper Concerns

When you hear complaints about the meetings in Scrum, it’s always a good idea to observe the meetings for a sprint, ensuring that they run on time and are accomplishing their purpose.

If meetings are going well, though, you might have to dig a little deeper to determine the cause of team complaints.

Often team members who complain that Scrum has too many meetings are complaining about something else entirely: the move to an agile way of working. I see this most often in teams who were forced into doing Scrum through a corporate initiative or top-down directive.

There’s a natural tendency to bristle at any command given from above. Calling the few generative rules of Scrum “too much overhead” may be a team’s way of expressing displeasure at having a decision pushed down onto them. Or it might be indicative of a team who doesn’t fully understand the why behind the move to Scrum. When people fail to see the reason behind something new, they get frustrated with having to do things differently and will resist the change.

In either case, the best way to achieve buy-in from these teams or individuals is to emphasize the benefits they will receive from Scrum, which include:

• Greater visibility into progress
• Closer contact with customers and users who can validate that the most-desired features are being built
• Closer coordination and greater communication with coworkers to ensure all team members are heading in the same direction, and more.

Scrum Shouldn’t Be a Burden

If Scrum feels too meeting-heavy or as if it has too much overhead, it likely is being done incorrectly or is simply misunderstood.

An astute Scrum Master will hear these comments as a warning signal and investigate to determine the true source of the problem. If you find that your issues go beyond sticking to a meeting timebox, and need help getting your teams on the same page about Scrum, we offer effective courses and consulting services.