If you have ever performed as a Scrum Master or agile coach you have been asked about the overhead in Scrum. Overhead is almost always a codeword for meetings where “stuff” happens but nothing is built, coded, or tested, which in a software-centric scenario will drive a coder or tester up a wall. If we exclude (for the time being) some really bad practices that have been promoted and adopted, the amount of time in Scrum specific meetings is generally predictable.

Christine Green, senior consultant and owner of IPbyGREEN suggests that meetings (also known as events or  . . . ) are influenced by three factors

1. Team Size – The number of people on the team or involved in the event. 
2. Delivered Size – The number of discrete pieces of work that are delivered by the sprint. Christine uses the term size to refer to the functional and non-functional size as measured by IFPUG Function Points. The concept of throughput accounting could just as easily be used. The concept boils down to how much valuable stuff will the team work on during the sprint. 
3. Length of Sprint – The number of weeks (or days) in a sprint.

Christine’s experience is that each meeting is influenced primarily by one of these attributes. Arguably, size and length have some co-variance – longer sprints will typically accept and deliver more work items than a shorter sprint. 

Using Scrum and guidance in the Scrum Guide (the guide provides the definition of Scrum)  as an example.

With the exception of refinement (in the Guide refinement is referred to as a flat percentage), the Scrum Guide suggests that events are shorter for shorter sprints. 

Assuming a typical Scrum team of 7 and 40 hours of productive time per person equates to 1,120 hours for a one month sprint (4 weeks to keep the math simple). The worst-case total meeting time for a one month sprint would be 252 hours (8 hrs planning, 5 hrs Daily Scrums, 4 hrs Sprint Review, 3 hrs Retrospective, and 16 hrs of Refinement — all multiplied by 7). The burden rate is 22.5%. OUCH! This is why people have the perception that Scrum has a lot of meeting time. FYI, the Burden Rate is the amount of non-engineering time divided by the total time expended on a project or sprint. A lower burden rate, all things being equal, is better but a zero burden rate would be just as horrid too much. Most team members intuitively measure and understand the concept of burden rate and work to avoid too much overhead. Most Scrum teams do not end up with a 22.5% burden rate unless they fall prey to a number of Scrum Faux Pas (also known as anti-patterns) because they find whys to avoid unnecessary meeting time.  In the next few installments we will explore:

1. Do shorter sprints have less overhead?
2. What are typical tweaks to Scrum to drive down overhead (and potential impacts)?
3. What is the burden rate for a typical SAFe implementation?