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. So for a 2-week sprint, the upper limit for each meeting would be:

• 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 also conducted as 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 common causes of this 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 (Traditional) meetings, which is a huge mistake. The Scrum Framework provides focus and helps teams get stuff done. In most cases, those other meetings 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 bad idea here.] By hybrid agile, what they really mean is that they’ve bolted Scrum on to their existing waterfall process.

The resulting Frankenstein mix is worse than either pure Scrum or pure waterfall. In an attempt to be agile, they layered scrum meetings on top of an already process and document-heavy methodology. That does not make it agile, BTW. If you see teams having a one-hour daily standup meeting, or tossing around the term “scrum of scrums”, 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. That 20% overhead per team for meetings continues to consume the majority of your available bandwidth. If you are on 3 teams, you will be in meetings for 60% of your time and each team will get about 13% of your bandwidth. 

And that is exactly what my training participants tell me. They don’t have time to do any work, so they go to the meetings to provide a status of 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 his or her job description. For example, in the daily scrum the Scrum Master ensures the team has the meeting and that it is kept within the timebox. Good Scrum Masters will provide feedback to the team to help them improve the effectiveness of this meeting. 

Secondly, the development team is responsible. We are all professionals and adults. We need to recognize circular discussions and rabbit holes and avoid them. 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.

#5 – The Team is Not Working as an Agile Team

Another dysfunction I see with so-called agile teams is that they are really a group of individuals all working separately on their own work. They don’t collaborate or pair, and the sprint backlog is essentially a set of tasks each person will do. They are not a true agile team. 

This team sees no value in the meetings because they don’t care to learn about or understand what other team members are working on. They don’t need to, since they are just a group of individuals. Often, they sit grudgingly through these meetings waiting to be asked about their work, while feverishly working on their laptop.

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, http://agilemanifesto.org/principles.html

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!

Ive come to believe that the real purpose of every Scrum Meeting is Learning:

• Learning what others are working on and what we can commit to as a team
• Learning about future backlog items so we can develop them
• Learning about what our stakeholders and customers really need
• Learning whether we developed the right product and if not, how to incorporate feedback
• Learning ways we might self-organize to achieve our sprint goals
• Learning how to improve the team processes to make them more effective and enjoyable

In fact, one measure of meeting effectiveness could be the amount of learning that occurs. You could quickly gauge learning by doing a quick retrospective with the team members at the end of the meeting to see how satisfied they were with the meeting, how much they learned, and what they could do to make the next meeting more effective.

Learning is the Key to High-Performing Scrum Teams

Learning is essential for agile teams to get to high-performance. 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 and achieve higher performance, you need to focus on learning.

Become a learning organization. That was the heart of the Toyota Production System and Peter Senge’s book, the Fifth Discipline.

I hope you enjoyed this post and I welcome your comments.