Scrum Events – The too many meetings problem

Nearly every team that I have introduced Scrum into a new company someone has complained at some point about the duration of meetings in Scrum. I get comments like:

“Scrum has far too many meetings”
“What? A four hour planning meeting for a two week sprint!”
“We have so many meetings here, and now you are killing us with more meetings”
“I cannot have my team in spending so many hours in meetings”
“I am too busy”
“&(#* off, this is &$%# @

Here are the events in Scrum and the hours for each event:


A novice team may see these numbers as big and a lot of time put into each event, however if you follow the principle of inspection and actually take a deeper look into the timing; you may be a little surprised with some of the numbers.

For math purposes, I will be assuming an average 9AM to 5PM job with an 8 hour workday. I will also assume a Monday to Friday job as this is common in just about all the teams I work with.

Here is the breakdown of time spent on each event in a Sprint:


2% Retrospection

Teams should spend time inspecting their processes and practices and seek opportunity to do things better and faster. Without this inspection and spirit to adaptation is completely lost and the essence of agility non-existent.

2.5% Review and Feedback

At the end of the sprint it is important for the team to speak to stakeholders and seek their feedback on the work they have just completed. This risk management strategy helps correct misaligned objectives early by allowing the team show what they have built and the stakeholders to agree or to correct it. Not spending time doing this feedback will simply result in the wrong product been delivered to stakeholders and not to their expectations. This supports the entire belief in incremental and iterative development with regular feedback.

Next is reviewing upcoming work and allowing the Product Owner to demonstrate the health of the pipeline of work to both the team and the stakeholders. It is facilitates transparent communication to the health of the product, project and upcoming work.

2.5% Co-ordinating daily effort

Each day the team simply have a 15 minute event to plan who is doing what for the next 24 hours until the next Daily Scrum.

5% Planning and Design

The largest Scrum event is to Plan the next sprint and to do high level designs on how the work will be approached. Traditional development teams spent way more effort on planning and design and Scrum team have totally reduced this. Yet this event is the most controversial event where teams feel it is still to long.

One must agree with Winston Churchill “Failing to plan is simply planning to fail”. I personally do not think ask any team for 5% of their time to plan and design upcoming work is a big ask. Surely a professional should be able to recognize the importance to plan.

88% Available to do work

That’s a lot of time to get stuff done. I do consider refining as work.

Here are some more facts

1 hour per day (average) in meetings

If you look at it as only having a single one hour meeting per day on average, this is actually not much at all in the grand scheme of things.

It’s a time-box

A time-box is the Maximum time for an event, this means that if you can do it quicker whilst delivering the same quality; then please do it quicker.

If you are doing more meetings than the ones in Scrum, then you are doing it wrong and the organization has dysfunction that needs to be addressed.

Here is the math for the skeptics:


Author Brett Maytom is a Professional Scrum Trainer.

where is your time going


Share This!


  1. Pedro

    Good post. However, I’m struggling in my company to get people understand this.

    My company tries to enhance a great culture, by having Company reviews every 2 weeks, Hakathons every quarter, charity events and many other activities that are great.

    However, when a delivery is getting closer, sprint ceremonies seem to be the least important ones. They just question its usefulness (specially for retrospectives and reviews. Also planning are painful because people don’t agree on estimations). However, they’ll cancel any company event, which I think add no value to the delivery.

    I understand the importance of the culture, but then, why not setting more realistic release dates that can be reached with all these events and ceremonies?

    Is there any advice you could give me here?

    1. Stacy Simones

      Pedro it sounds like your company could benefit from some Agile leadership training. When leaders understand the importance of the ceremonies in your Scrum cycle, they’re able to prioritize other company events around those ceremonies. Props to your company for putting so much effort into their culture – a lot of places still don’t recognize culture as an important part of doing business. Maybe you could approach your leadership team with the cultural benefits derived from strong Agile leadership practices? Meanwhile, we’ll give some thought to a blog post about this issue to provide you with a few small first steps. Check back for that soon!

  2. Anna

    This breakdown may technically be true, but how much uninterrupted work time do you actually get? My issue isn’t the total number of hours I have available to work, but how they’re broken up by meetings. Only getting an hour here, 2 hours there to work kills my productivity. I’m not a robot – I need time to get in the mode, to process the new info I just got in the meeting, to get my head around the issue, and then get to work. I have to switch from planning / talking / social mode to head down working mode. This isn’t easy when nearly every day is broken up with meetings (even if they’re each only 15 minutes, those meetings and the buffer period between them add up).

    1. Andre Simones

      Scrum only requires one 15 minute meeting (Daily Scrum)/per day. It can be any time of the day, but my own preference is to knock it out first thing in the morning. So theoretically, if you’re working an 8 hour day, you should be able to get 7 hours and 45 minutes of uninterrupted work time. If there are other daily “required” meetings, this is not part of Scrum.

      A team member should only be on one Scrum team. If you’re on multiple Scrum teams then you’ll have to attend multiple Daily Scrums which is very disruptive. I’ve seen people that have been on 4+ teams and basically they get zero work done. If people are part of multiple Scrum teams, then this should be raised as an impediment and be addressed.

  3. Marjan

    Maybe my arithmetic is failing me, but how do you get from 78.1% development (in the pie chart) to “88% Available to do work” (in a sub heading and the call to action at the bottom)?

    It seems you left the product backlog refinement out of your math. Why?

    It isn’t development, it isn’t (high level) design – which is done during sprint planning according to your description of it. It’s mostly a conversation with the product owner to ensure that what is requested is clear and can have an estimate slapped on it.

    1. Andre Simones

      The author includes backlog refinement as work later on in the post … “I do consider refining as work.”, under the heading “88% Available to do work”, so yes it was kept out later as it was defined a “work”. Since refinement isn’t a scheduled event, and there’s no real time-box (the scrum guide just says it should take no more than 10% of the team’s capacity) it was left out of the math.

      Now, you could potentially even go further, and say that “work” is anything that provides value, i.e. conversations, clarification, planning, etc. And if these “meetings” (events) are widely perceived as waste by the team then there’s something seriously wrong. But, we’ll save that for another post 🙂

Leave a Comment

Your email address will not be published. Required fields are marked *

post =