There Are Too Many Scrum Meetings

There Are Too Many Scrum Meetings

A pretty common complaint with the Scrum Framework is that there are too many Scrum meetings. Let’s explore this complaint to understand if it is valid, why it might occur, and what to do about it.

Are There Many Meetings in Scrum?

If you count 4 as many, I guess you could say there are many meetings in Scrum. Or if many means frequent, there is at least one Scrum Meeting per day. Is that many?

And it seems that most people like to hate meetings. It is as if they feel that all meetings are wasting time. That they are not productive when they are in a meeting.

This also seems to imply that the opposite is also true – that team members are productive if they are back at their desk. Which I doubt is actually true, at least not true all the time.

I had a conversation with a Product Owner recently who wanted to shorten all the Scrum Meetings he attended. He complained that he was double booked all day, didn’t have time for it. He also stated that he wanted to make sure everyone was efficient. His implication is that if people were not at meetings, they would be able to work non stop for 40 hours a week and they would all be “efficient”.

I told him that would be like running the 26 miles in a marathon without slowing down or taking a break for water or to walk. Yes it can be done, but only the elite runners do it. The rest of us take breaks.

How Many Scrum Meetings are there Really?

There are 4 official events or Scrum meetings in the Scrum Guide and each has a timebox or upper limit on how long they can be. The Scrum Guide used to say that each meeting is proportional to the length of the sprint; now it simply states the timebox for a month long sprint and says shorter sprints should have shorter meetings.

I prefer the previous approach and reduce the timebox for each meeting to be proportional to the length of the sprint:

  • Sprint Planning – 4 hours
  • Daily Scrum – 15 minutes / day
  • Sprint Review – 2 hours
  • Sprint Retrospective – 1.5 hours

Those are the 4 official meetings but there is another activity, product backlog refinement, that is usually a meeting. Product backlog refinement is generally accomplished with the team and the product owner via meeting. So we need to consider that in our estimate.

The Scrum Guide says up to 10% of a teams capacity should be allocated to backlog refinement. That would be 8 hours for a 2 week sprint. I generally find that teams need much less than that – even half. For argument’s sake, let’s put it at 6 hours of backlog refinement.

  • Backlog Refinement – 6 hours

In terms of totals, that is a maximum of 16 hours of meetings for a 2 week sprint, or 20% of a team’s capacity. Remember, these are timeboxes so those are the maximum and teams can use less time.

So what is all the fuss about 16 hours of meetings in a 2-week sprint?

Why All the Complaints about Scrum Meetings?

Why are there so many complaints about the 4 official Scrum meetings and one activity (Product Backlog Refinement) that constitute 20% of the team’s capacity? There are several reasons and most of them are about improper use of Scrum.

#1 – Still Doing All the Other Meetings PLUS the Scrum Meetings

Many people that adopt Scrum keep all their existing meetings, which is a huge mistake. The Scrum Framework provides focus. In most cases, every other meeting that teams attended before Scrum are no longer essential and can be replaced with the Scrum Meetings.

#2 – Hybrid Agile; Scrum Meetings Added to Existing Waterfall Process

Similar to the previous item, some organizations want to use hybrid agile approaches. [Read why I think Hybrid Agile approaches are a terrible idea here.] By hybrid agile, what they really mean is that they’ve bolted Scrum Meetings on to their existing waterfall process.

In an attempt to be agile, they layered scrum meetings on top of an already process and document-heavy methodology. That did not make it agile, BTW. If you see teams having a one-hour daily standup meeting, they are probably using “hybrid agile”.

#3 – But I am On Multiple Scrum Teams

Another frequent cause of the complaints of too many meetings is when people are assigned to multiple Scrum Teams. I’ve had participants in my training classes talk about being on 3, 4 or even 5 Scrum Teams. It doesn’t take a genius to figure out that pretty much all your time will be spent in meetings if you are on 2 or more teams.

And that is what they tell me. They don’t have time to do any work, so they go to meetings to talk about all the tasks that they are not doing, because they are always in meetings. Can we stop this madness?

#4 – Lack of Skillful Facilitation

Another cause of too many meetings is when each meeting is not facilitated well. It is common that teams waste their time in meetings, have endless circular discussions, lack focus, and run over their time box. Yes that is a problem.

Who is responsible for effective meetings? First, the Scrum Master. That is pretty much part of her job description.

Secondly, the team is responsible. We are all professionals and adults. We need to recognize circular discussions and rabbit holes. Sure the Scrum Master should help with this, but we all need to be responsible. A good Scrum Master will teach their team how to effectively facilitate their own meetings.

What is the Point of All Those Scrum Meetings?

The main reason to meet together is to exhange information and do it with minimal loss. To communicate. There is an Agile Principle that speaks to this:

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

  • The Twelve Principles behind the Agile Manifesto,

Interestingly enough, most team members that hate meetings tend to like communications, What are some of the communications that we need to have as a team?

  1. Synching up
  2. Decisions
  3. Collaboration
  4. Learning

Actually I think all of these could be summarized as LEARNING.

The Purpose of Every Scrum Meeting is Learning!

The purpose of every Scrum Meeting is Learning:

  • Learning what others are working on
  • Learning about future backlog items so we can develop them
  • Learning about what our stakeholders and customers need
  • Learning how to improve our product
  • Learning how to improve our process

The measure of every meeting should be Learning. Team members can record their learning satisfaction after every meeting.

Amir Elssamadisy in his book Agile Adoption Patterns: A Roadmap to Organizational Success states that “Learning is the Bottleneck for Software Development Teams”. In other words, to go faster you need to focus on learning.

Become a learning organization. That was the heart of the TPS and Peter Senge’s book.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Close Menu