Archives for 10 Mar,2015

You are browsing the site archives by date.

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