Blog

Scrum Events – The too many meetings problem

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:

Time-Spent-on-Events-Graph1

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:

Scrum-Events1

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:

Event-Times-for-Sprint1

Author Brett Maytom is a Professional Scrum Trainer.

where is your time going

 

10 Comments

  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 🙂

  4. Anonymous

    I think one big flaw of the calculation is that you assume the capacity of an FTE is 8hrs/day. Usually, the capacity is calculated by taking 75-80% of a full day. So, if you are an FTE and expected to be in the office 8hrs/day, your capacity is actually 6-6.5 hrs/day. The issue I am experiencing is mentioned by Andre Simones above. At my company the only people that are 100% allocated to a project are the trio. Most of the other team members are anywhere between 10-80% allocation. I am struggling with attending the ceremonies for a project where I am allocated 20%. If you do the math, at 75% capacity, I am allocated only 12 hours to the project. So, if you have 5 hours of ceremonies, that’s almost half of the work time.

    1. Andre Simones

      Assigning people to multiple Scrum teams with a small allocation on each team is a management dysfunction. This didn’t work in traditional/waterfall orgs (even though everyone pretended it did) and it doesn’t work on Scrum teams. It just makes it more apparent on Scrum teams.

      Scrum is doing it’s job in this case, it’s exposing an impediment (people on too many projects). It needs to be recognized as an impediment and taken care of. If it’s not, then the org has a profound misunderstanding of Scrum and especially Agile and Lean.

      Unless you are truly on a shared services team (Networking, Accounting, Legal, etc), you should only be on one Scrum team.

      Organizations that are project based will move people around to “assign” them to various teams/projects. This is backwards, projects should be assigned to teams. Alas, this is a topic for another blog post 🙂

  5. J

    I don’t quite agree with the logic that says “78% development”.

    There seems to be an unrealistic, oversimplified assumption that all team members are local while in reality my experience is quite the opposite.

    Nowadays with ever-increasing cost cutting and outsourcing of development (in places such at India) in different time zones we end up having to spend *lots* of extra time communicating with remote people that are poor at doing efficient collaboration/communication. Often these people are not very educated and poorly qualified to do the job.

    Having to do these meetings with these people increases the time needed (if they are part of the meetings) increases the time of the meetings (since work requests, specifics etc are often lost in transition and need to be repeated). Culture difference brings extra challenges into the mix too.

    And even if remote people aren’t part of the meetings, you still need to collaborate with them and that takes a toll on that “78% development” slice of the pie.

    1. Andre Simones

      This definitely isn’t an exact science. The main point is that if you time box appropriately, focus on reducing waste (including nonsense meetings), and aren’t on multiple Scrum teams, there are actually fewer meetings (from my experience anyway) than in a traditional shop.

      That being said, I completely agree with the reality you describe and have personally experienced it many times. Once you put cost cutting above creating a high performing, cross functional, self-organizing team, then you really aren’t doing Scrum or any version of agile at all. You are sabotaging all potential success. The team members MUST be at a similar experience and skill level. Having complimentary skills are great, and actually desired. But they’d better be damn good at what they do. Of course you’d want one or two junior team members that the team can mentor to become great team members.

      In the “perfect” agile world, the team members would have the ability to say NO to additional team members and even be able to hire who they want (with budget approval of course). An incompetent team member does far more harm than good.

Leave a Comment

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