One of the most common complaints about using Scrum is the amount of meeting time. In How Much Meeting Time, we used the meeting length recommendations from the Scrum Guide for a one month sprint to calculate the meeting burden rate. The number was 22.5%, assuming everyone is involved in each meeting and the meetings toe the line in terms of the guidance provided. One of the common recommendations to mute the meeting overhead problem is to use shorter sprints or iterations.
One of the common pieces of advice is that many of the meetings scale (or de-scale linearly). If 4 weeks is 4 hours, 1 week would be 1 hour. While this common advice is reasonable, it is not part of the Scrum Guide. I pinged a few practitioners that I had not trained and heard the same advice, so we will use this assumption, along with the guidance on involvement from the Guide. Using the same table as before for a 2-week sprint.
Meeting | Driver | Scrum Guide Guidance for 2-week Sprint |
Sprint Planning | Size | Maximum of 4 hours |
Daily Scrum | People | 15-minute time-boxed event daily |
Sprint Review | Length – Size | 2-hour meeting |
Retrospective | Length | 1.5-hour meeting for one-month Sprints |
Refinement | Length – Size | No more than 10% of the team capacity |
Assuming linearity and the same 7 person team working 40 productive hours a week equates to 560 hours for a 2-week sprint. The worst-case total meeting time for this length would be 126 hours (4 hrs planning, 2.5 hrs Daily Scrums, 2 hrs Sprint Review, 1.5 hrs Retrospective, and 8 hrs of Refinement — all multiplied by 7). The burden rate is 22.5%. Ouch. But that ouch is no different than the percentage time stuck in meeting for a one-month sprint! [This mental experiment suggests shorter sprints would be just as meeting bound as longer sprints with over ⅕th of the team’s time stuck in meetings. A straight read of the Scrum Guide does not indicate that there will be less meeting overhead, arguably since the Guide is mute on whether the ceremonies scale linearly the level of overhead could go up. Fortunately, this is not what happens in the real world or at least shouldn’t (I have noted before that there are a lot of bad implementations of Scrum, agile, and other development approaches).
Let’s pick on the longest tent pole, refinement, to challenge the assumptions. There are several problems with using a blanket 10% and involving the whole team. The first issue is that 10% is a maximum; in my experience, the amount of effort is closer to 5 – 7% and falls as the team gains a higher understanding of the backlog. Secondly, many teams use an approach that only involves part of the team for refinement (one approach is Three Diverse Humans – formerly known as the Three Amigos). In both cases, the amount of meeting time is reduced, but there is no indication that the percentage of time in meeting changes based on sprint duration.
There is no prima facie evidence that the meeting burden rate changes based on the number of weeks in a sprint, even though there is anecdotal evidence that individual implementations of Scrum and hybridizations such as Scrumban are different. We will explore how some of the anecdotal observations can be true.