Does Scrum generate a Project Overhead?

In project negotiations I’m sometimes getting told that Scrum is not an option at customer side as cooperation model. From Customer point of view Scrum generates a management overhead, by a lot of additional meetings and customer doesn’t have whether capacities, nor won’t pay for. Of course such statements came from Scrum Newby’s, however lets make an example calculation of „overhead“ and find my conclusions from the field about.


First let’s imagine we do a one-week sprint. As you know all rituals in scrum are time boxed relatively to sprint length. Only exception is daily Scrum Meeting, that is always 15 minutes in maximum. I’ve visualized below possible schedule of all rituals, while light gray area’s is „productive“ implementation time.

Already according the painting above it’s visible that there is just a minimal „overhead“. However, lets make a example calculations: 
  • a development team of 5 Full-time Employees (FTE’s)
  • a day has 8 working hours
  • Scrum Master is attending all Meetings, that is covered by a Scrum Expert of the 5 Developers 
  • Product Owner is as much as possible accessible by team and will attend all meetings of Scrum
Topic Capacity [Hours] Description
Total Capacity of Development Team 200 [COUNT OF FULL-TIME-EMPLOYEE] X [8 HOURS] X [5 DAYS]
Scrum Master „Overhead“ – 4.75 [PLANNING] + [ALL DAILY SCRUM’S] + [REVIEW] + [RETROSPECTIVE]
„Real“ Team Capacity 176.25
Product Owner „Overhead“ 4.75 [PLANNING] + [ALL DAILY SCRUM’S] + [REVIEW] + [RETROSPECTIVE]

Find below my conclusions related to the calculations of various „overhead’s“ above:

Using Scrum the team has in general a productivity time of 88.1%. From experience everything more than 80% is very good comparing to traditional approaches. As Scrum keeps Product Backlog Items ready in advance, continous delivery and high workload is guaranteed. If we break down „overhead“ for one employee we’re talking about 4.75 hours per week. If we reduce this by 3 hours of planning/review meeting, that could be counted to productive time too, a team member just „looses“ 1.75 hours. This could be explained as a regular weekly status meeting in a traditional approach, without benefits of Scrum in general.
Scrum Master
The Scrum Master won’t usually attend to all the meetings, but he ensures that those take place. However, there are other tasks e.g. removement of impediments, facilitation of team members, etc that need additional time. From experience 1.9% time usage for Scrum Master could be realistic for a well rehearsed scrum team. On the other hand development teams in traditional cooperation models are not self organized and need a team leader in area of 20% similar to a technical project manager, that will be for sure more than time usage of a Scrum Master.


Product Owner
Even if Product Owner needs additional 10% of his time for direct clarifications an experience Product Owner could work it out with 11.9% of his time. This is far away better than usual time needed for Project Management (usually 20% in minimum), Business Analyses (30% of all project time), etc. This contains just cooperation with team and obviously time for stakeholder management, product refinement, etc have to be added. However this customers often forget to count in traditional approaches.


In general Scrum generates a smaller overhead for additional meetings, than traditional approaches. But those meetings ensures continous communication and delivery. Together with the short delivery cycles and the daily Scrum Meetings Scrum reduce risks and ensure business success. On top Scrum could improve delivery performance 2 – 8 times and spare additional costs by delivering faster. 
Sorry Newby’s, don’t denounce Scrum if you don’t know it :-). 

Mirko Kleiner is a Blogger, Agilist (Agile Evangelist), Vice President Delivery at youngculture AG, Twitterer, Father of 2 beautyful Sons and Partner of a lovely Wife.

Tagged with: , , , , , ,
Veröffentlicht in scrum
2 comments on “Does Scrum generate a Project Overhead?
  1. Hans-Peter Korn sagt:

    Sorry, you are mixing up different issues:
    Scrum is no.PM-Method.
    As Ken Schwaber said:
    „SCRUM is a management, enhancement and maintenance methodology for an existing
    system or production prototype. It assumes existing design and code which is virtually
    always the case in object-oriented development due to the presence of class libraries.
    SCRUM will address totally new or re-engineered legacy systems development efforts at
    a later date.“ (see

    So: There is not one PM-activity in Scrum. Maybe Scrum – as a team-management methodology – is embedded in a PM-methodology like PRINCE2.

    And: „Plannings“ in Scrum (as well as the Backlog Refinements, usually consuming no more than 10% of the capacity of the Development Team) are no „management acitvities“. Most time of this „events“ is invested to clarify the content (not the management) of the work.

    • mirkokleiner sagt:

      just to clarify, I’m aware of that Scrum is not a PM Methology. But Scrum is often used in short therm development cooperations i.o.w in projects where a delivery team is offered using scrum. In such a negotiation phase the story plays above.

      „Scrum is a way for teams to work together to develop a product. “ by

      .. and a product development could be done in a short therm cooperation/project too :-).

Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

Du kommentierst mit Deinem Abmelden / Ändern )


Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )


Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s



Mirko Kleiner is a Blogger, Agilist (Agile Evangelist), Vice President Delivery at youngculture AG, Twitterer, Father of 2 beautyful Sons and Partner of a lovely Wife.

Verifizierte Dienste

Vollständiges Profil anzeigen →

%d Bloggern gefällt das: