Get certified - Transform your world of work today


Scrum Shouldn't Be a Burden

20 March 2006

Mike Cohn
Mountain Goat Software


After some time off in December I've been back on the road and traveling every week since the start of the year. In that time I've noticed something new: people are telling me that Scrum is too much overhead. Too much overhead? I don't think so...

“Too much overhead” isn't a complaint I heard at all last year, but I've heard it a handful of times since the start of 2006. These comments have surprised me—Scrum requires only a single fifteen-minute meeting each day plus a half- to full-day at the start and finish of a sprint. That doesn't seem like much overhead. However, by studying the teams doing the complaining, I have uncovered three reasons why some groups might harbor these misconceptions.

First, the teams may really be complaining about something else entirely. Comments like these could be symptomatic of Scrum adoptions that were started outside the teams. These teams, in effect, have been told that they will do Scrum because doing so has been established as a corporate direction. I believe there's a natural tendency to bristle at any direction given from above. Calling the few generative rules of Scrum “too much overhead” may be a team's way of expressing displeasure at having any decision pushed down onto them from above.

Second, it is possible that Scrum could look like a lot of overhead to a team that was running with almost no process at all. However, I'm skeptical of the ability of a team to consistently deliver valuable products with much less “overhead” than Scrum. There just isn't much that you could cut out of Scrum in order to reduce overhead. In one of the cases I encountered, the perception of Scrum's overhead seemed to stem from the cost of iterating every two to four weeks. Prior to adopting Scrum, this company was not using an iterative process at all. The need to periodically drive the software to a shippable state must have felt like needless overhead to some individuals in that company. On the other hand, their prior process led to late products that missed on fully fulfilling market needs.

Third, the individuals who believe Scrum is a lot of overhead may not fully understand it. They may be looking only at the new things they have to do (daily Scrum meeting, sprint planning, sprint review, and so on). They may not yet see the benefits they will get from Scrum, such as greater visibility into progress, closer contact with customers and users who can validate that the most-desired features are being built, closer coordination and greater communication with coworkers to ensure all team members are heading in the same direction, and so on.

If Scrum feels too heavy or if it has too much overhead, it likely is being done incorrectly. I first ventured into Scrum because I desperately wanted a process that would allow me time to work as a manager of teams but also to program on the systems we were developing. Scrum appealed to me because it was lightweight, the management needs were low, and it wouldn't take much of my time away from programming. Those characteristics just don't mesh with complaints of high overhead. An astute ScrumMaster will hear these comments as a warning signal and investigate to determine the true source of the problem.

Mike Cohn is the founder of Mountain Goat Software. He is a Certified ScrumMaster trainer and is the author of Agile Estimating and Planning and User Stories Applied: For Agile Software Development. Mike is a founding member of the Agile Alliance and the Scrum Alliance. Mike can be reached at

Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.

Article Rating

Current rating: 5 (1 ratings)


James Tischart, CSM,CSPO, 5/1/2008 7:54:13 PM
Mike, we are struggling with this right now, I believe that another reason why Scrum can feel like too much overhead are the demands put on to the Scrum team from outside departments. When Agile direction is not shared with the entire company and the benefits are not explained, you tend to fall into Agile wrapped around a Waterfall process. In my opinion it is the Scrum Master and Product Owner's duty to work with these groups to help them understand that their demands on the team to produce legacy type documentation, or have meetings to discuss every decision that is made, can also feel like a burden and slow down the teams velocity.
Mike Cohn, CST,CSP,CSM,CSPO,REP, 5/1/2008 8:53:55 PM
Hi James--

You are absolutely correct. I've been working on a new book and in it I describe five steps or phases that I've noticed occur in successful transitions. The final phase is what I call "Transfer." It refers to the need to transfer the impact of being to other parts of the organization. If the impact of agile isn't transferred to those other groups, I contend there is often "organizational gravity" that pulls the team back to how they worked before. So, I completely agree with your points above.
Peter Nelson, CSM, 5/6/2008 8:04:05 AM
We are working on our adoption of Agile/Scrum as well. I regularly hear the complaint, or "obstacle" (at a daily standup) of "too many meetings." Of course, since developers are inherently empirical (dare I say "binary") they should be less prone to hyperbole than most. However, if they did the math, I'm sure that they'd find other diversions and distractions (many of their own making) are equally if not more guilty than a "real" meeting. But that aside....

From our less than functional past, without these meetings things were not implemented as the customer/product owner had envisioned. This is particularly vexing to me since we are a relatively small shop with only moderate remote workers. So as the ScrumMaster here, I am trying to facilitate more of these meetings (not too long in duration) to get people to spend face time to (hopefully quickly) talk through these things. The "subversive" goal is to get more communication between all of the constituencies.

Our pilot project using Agile/Scrum (and Rally Software's tool) was quite successful. Not perfect, but so much better than previous projects. I think if you can create the opportunity for an incremental "win" that will also help to quicken acceptance.
Alicia McLain, CSP,CSM,CSPO, 5/6/2008 11:36:44 AM
To Peter, we too had that complaint initially. The mis-understanding that Sprint Planning 1 is not the same as a Project Management Cross Functional Meeting (meetings they felt were a waste of time). [Sprint Planning 1 and 2 are vital to design and discovery..and its part of the work that needs to be done. We had to CLEARLY make that distinction so folks 'got it'. Even to the point of taking the work 'meeting' out of the definition of these sessions. This misunderstanding actually led to a complete internal overthrow of our development organization. They felt the development organization wasn't using its time wisely so the project management organization took over...only to find...Sprint Planning 1 and Sprint Planning 2 are vital to design and discovery...that the way an engineer works (creative process) is quite different than the way.. say someone in another department like accounting or even project management might work. We have a pretty small shop and our effort was totally grassroots so this lack of executive buy in caused a lot of misconceptions about how it all works....We still use it today...its still growing in acceptance!
To Mike: In terms of overhead, our developers laser beam focus on writing out task cards as being the most excruciating of 'to do' items in this process. They don't complain much about anything else. They want an electronic tool badly. I personally feel the big picture isn't as openly visible...the 'feeling of moving a task card from 'In Progress' to 'Done' isn't as tangibly felt...There are some that feel like the use of task cards and a cork board is pre-historic and 'unnatural' for a software development company. When I train all of the new engineers and share with others who are interested in getting an overview...I tell them who's doing it and how they do it so they don't think this is something cooked up internally. But it remains a challenge.
Nirmaljeet Malhotra, CSP,CSM,CSPO, 8/14/2010 8:50:59 AM
Mike, I have been talking to a lot of teams at my current client place and also companies where my friends work and I feel that the basic principles of Scrum are being ignored. I truly feel that the Scrum Master is the one to blame.

In most cases, Scrum for teams is all about a daily standup. After that, it is all what they feel it is. Even the stand ups go on forever where all the issues in the world are discussed. Some of the most common issues I see include:

1. Someone with no practical working knowledge of Agile processes is the Scrum Master
2. Teams are in meetings all throughout the day
3. Most teams are doing mini waterfalls
4. Lack of use of available and proven tools and techniques
5. Teams coming from a waterfall background are expected to be productive after a 2 hr Scrum primer
6. Individual perception makes a big difference

Frankly, you can fix some but not all. As said, transformation to Agile has to come from the top in a structured fashion and should not be looked at as a switch to change mindsets.
Stacia Viscardi, CST,CSM,CSPO,REP, 6/16/2011 7:19:28 PM
Mike, great article. I've encountered the 'too much overhead' complaint lately at a large enterprise I've been coaching. After a little digging, I learned that the ScrumMasters were updating the sprint backlog for the team members during the daily scrum meeting; thus what should have been a 15-minute meeting turned into an hour due to some "ScrumMaster" really not understanding the reason for the daily scrum (visibility and synchronization amongst team members, not status for the scrummaster). I also encounter teams from time to time who feel that the daily scrum meeting is useless; upon closer inspection of these teams, I learn that they team members really aren't working together but instead are a group of individuals each working on and burning down their own tasks, with no interest in what everyone else is doing.
Stacia Viscardi, CST,CSM,CSPO,REP, 6/16/2011 7:21:59 PM
Of course, these strange implementations are not 'scrum' and should be corrected.

You must Login or Signup to comment.

The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.


Newsletter Sign-Up