There Are Too Many Scrum Meetings

too many meetings in scrum

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,

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.

Related Posts

By Anthony Mersino

Anthony Mersino is the founder of Vitality Chicago, an Agile Training and Coaching firm devoted to helping Teams THRIVE and Organizations TRANSFORM. He is also the author of two books, Agile Project Management, and Emotional Intelligence for Project Managers.


  1. 64 / (1.5 + 2 + 6 + 2.5 + 4) = 4
    One fourth of the theoretical working hours is dedicated to meetings.
    That’s not what your pie chart shows…

    1. Dear Anon,

      Thanks for your comment. The pie chart should show that 16 of the potential 80 hours in a 2-week sprint are dedicated to meetings, leaving 64 hours as hours that other work could be done. That 64 is what I labeled ‘theoretical’ – it is time outside the meetings.

      16 / 80 is 1/5 or 20% if my math is correct

      Of course not all organizations have a 40 hour work week so this would need to be adjusted if teams work more or less.

      If this is not clear, please let me know or email me directly at:


  2. I love how this guy provides this very unrealistic breakdown of a pie chart. A typical scrum meeting is not 15 minutes, it’s 30 minutes if you’re lucky – PER PROJECT. Maybe the author lives in some fantasy world where people only ever work on one project at a time until it’s completed, and then onto the next. The reality is most people are working multiple projects and scrum meetings will take up *at least* 1.5 hours per day, and each often overrun by another 15-30 minutes. Most of the time those three scrums will take up closer to 2.5 hours per day, or 12.5 hours per week – 25 hours for a two-week period. Not sure why the author chose a two-week period but I can only assume it’s to try and reduce the glaring truth that scrums will take up a very significant portion of a work week. It’s worse if you have more than three projects at a time, which sometimes happens.

    But hey, those scrums are really useful, right? I mean how can a project get done without a daily meeting? The reality is projects were completed on time and within budget for decades before scrums ever appeared. Just meet when there’s something to meet about – there’s no need for a daily meeting unless you’re really into micromanagement. Also studies indicate that people cannot just mentally shift instantly from working on something, to a meeting, and back again. There’s a certain overhead associated with a task switch, and it can be taxing if someone is spending 30+ minutes in a scrum just listening to people talk because that person is completely on-schedule and has nothing new to add in the scrum. So no, a daily meeting is not useful, it’s just a time sink so some “black belt” can check a box that they are “Agile”. By the way I’ve often noted that these “black belts” seem to spend the absolute minimum time needed as a developer before they move into management, often leaving behind a mess of spaghetti that will take an actual developer some time to straighten out.

    In over 35 years of software development at dozens of companies the only thing I’ve encountered less agile than Agile is ISO-9000 and it’s descendants. It always amazed me in my time as a contractor how companies would want to pay my fee to just hang on a phone for a scrum as opposed to getting their product finished, but if they want to pay for me to have a coffee then okay, into the billable hours the scrum goes.

    1. Nate, thanks for weighing in! I think your comments speak for themselves and why Scrum isn’t for everyone or all projects. If you are running from one Scrum meeting to another, or spending 2.5 hours per day in daily meetings, then don’t use Scrum.

      For you Nate, I would recommend that you stop doing all those daily Scrum meeting. Check this out:


  3. I am interested to see what other people’s views are.

    This is for a regulated industry – financial services
    > This is with management consultancy doing the Dev and test work
    > 2-week sprints
    > Developers calculate story points on difficulty eg: “3”, “5” or “8” – this is not days or hours, I asked them and it has no measure. (so is meaningless)

    1. Are they supposed to understand the business system they are working on (not just that they can code).
    2. Are they supposed to understand the business domain they are working in
    3. Are they supposed to understand databases (eg: Relational, Star) – how they work

    What if the developers don’t understand any of the points above?

    1. Are they supposed to understand the system they are working on (the functionality).
    2. Are they supposed to understand the business domain they are working in.
    3. Should they know how to write test cases
    4. Should they know how to produce the evidence

    What if the testers don’t understand any of the points above?

    What is happening
    > Both are expecting stories to be at detailed specification level – telling them “how” to build and test the system
    > Test cases and test evidence is being rejected – no business domain knowledge also not qualified testers

    Meetings per day
    > Daily scrum – 15 – 20 min
    > multiple meetings – (mini-workshops) of 30 min to an hour per meeting 4 or 5 times a day
    > with (business analysts, product owners, architects, other software system teams).
    > A refinement last call in the afternoon (30 min) to see who has issues.

    1. Andy, thank you for your comment. This is really not a question about how much time should be spent in meetings. This is about organizing a team and selecting the way they are going to work together using agile or more traditional/waterfall approaches.

      Has everyone agreed to use Scrum? If so, why? Has everyone been trained to use Scrum? Applying the Scrum framework in an environment where you have outsourced development provides some additional challenges. The “management consultancy” seems to be following more of a waterfall approach. If the developers and testers are spread across multiple teams or projects, or assigned on a short term/temporary basis, there may be little incentive to learn the context.

      I would expect that in the context that you described there would need to be a lot of meetings because the people doing the work don’t have context or understanding. One path forward is frequent meetings or conversations with the Product Owner, Subject Matter Experts and others who have the details so that the team learns.


  4. Hi Anthony,

    Thanks for your quick reply, you have stated what should have been done and I agree with your comments.
    I agree this should have been an “iterative Waterfall” approach.
    There are a lot of continuous meetings with the product owner and architects. The company was told and believed that Scrum (Agile) was a quick way (silver bullet) to get a full platform built.
    Even with all the meetings, the business domain skills of the consultants do not increase.
    There is a lot of basic business knowledge that is not in place. I have raised this with management, that is as much as I can do.

Leave a comment

Your email address will not be published.

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