Scrum Has Too Many Meetings

The Scrum events fit nicely into a sprint. Sprint planning, the daily scrum, sprint review, and sprint retrospective are all time-boxed, meaning they have a maximum duration that the team can’t exceed. Here’s an example of what the events in a one-month sprint might look like; you can tailor the duration of these events to suit your situation:

When you map these events out over a sprint, it doesn’t seem like Scrum is meeting-heavy, but after a few sprints the development team members might start to make comments about Scrum being meeting-centric:

“There are just too many meetings in Scrum. I never have time to get real work done!’’

“These meetings take forever. Our daily scrum is 45 minutes at minimum, I can’t remember the last retrospective that didn’t run over into lunch, and sprint planning takes multiple days to complete.’’

“Scrum was supposed to put the focus on the team, but it feels like the focus is on my calendar.’’

Let’s look at some reasons why this happens:

• Violating the time box: If your Scrum events are going past the allotted time, you need to take a hard look at why the team isn’t able to accomplish the goal of the event in the scheduled time.

• People on multiple teams: Developers who are assigned to multiple teams have to attend Scrum events for each one. Consider single-team assignments.

• Bad facilitating: The events are within the time box but the team isn’t making adaptations. For instance, if people aren’t engaged in a sprint review or sprint retrospective, perhaps it’s time to change the format.

• Old meetings still on the calendar: This is the most common issue. Every Scrum event was designed to replace traditional meetings. If your development team is still bogged down by their calendars, it’s time to cut some meetings.

Every Scrum event is designed to remove the need for many of the meetings you had previously. The sprint length sets the cadence for how often we’re going to meet with stakeholders, how often the team is going to meet with one another, how they’re going to work together—it creates all the boundaries and containers for the work to happen within.

The sprint promotes collaboration. We can use sprints to help management learn how to interact with the Scrum team. It’s incredibly powerful for management to have the ability to see finished work, just as it is for the stakeholders, and that can promote healthy and positive ways of interacting with the Scrum team. So what does that mean?

As opposed to having management swoop in every day looking for updates, you can work with the management team to say, “Every two weeks we have a sprint review that you’re invited to where you can see finished work. Oh, and by the way, we have a team board and we have information ready that you’re always welcome to view.”

By working in a cadence, having the Scrum artifacts up to date, having a sprint review at a regular interval, and allowing management to participate and see the work, you’re helping to teach people how to interact with the Scrum team by using the Scrum events as designed.

Bottom line: Help your team members clear their calendars and get to work.