You Should Stop Doing Daily Scrum Meetings


I recently wrote about how to improve your Daily Scrum meeting. Now I think that we should just cancel the Daily Scrum altogether.

To be fair, some people are using the daily Scrum meeting effectively. Team members start the meeting themselves and use the time to collaborate and replan their work to achieve their sprint goal.

More commonly, I find that people are abusing the Daily Scrum and for them, I recommend that they stop the Daily Scrum meeting.

One of my agile coaching colleagues, Tom Cagley, shared with me similar experiences and frustrations. It was our discussion that inspired me to write this post.

How Teams Are Abusing the Daily Scrum Meeting

The most common abuses of the Daily Scrum include:

  • Using the meeting as a daily status meeting
  • The Scrum Master or other non-Dev Team member interviews (or interrogates) each person about their status
  • The daily scrum takes 30 minutes or longer
  • The meeting moves slowly because the team is tuned out or watching absentmindedly while the Scrum Master updates tasks and backlog items in an online tool
  • Using the meeting to reinforce power positions and tell people what to do (Ron Jeffries describes this as Dark Scrum oppresses the team every day)
  • Team members are tuned out and not listening to each other
  • Team members don’t talk about tasks that aren’t getting done or asking for help
  • Impediments are either not discussed or they are brought up and not addressed by the Scrum Master or others
  • Dev Team members are going from one daily Scrum to another to report on tasks they didn’t get done, and it eats up their entire morning (note that this is not a fault of the daily Scrum but rather because someone assigned the Dev Team Member to work on multiple Scrum teams in an effort to get more done)
  • The Scrum Master takes notes during the meeting and publishes them as meeting minutes
  • The meeting is delayed until a Scrum Master, PO or manager arrives, or worse, the team is forced to restart the meeting for the PO or manager who arrived late
  • No one in the meeting focuses on the team goals for the sprint or how they are adapting to achieve those goals

Fake Scrum Teams – Sometimes the daily Scrum is made irrelevant because there is no need to communicate during the sprint. Some so-called ‘teams’ are actually just a collection of people doing individual work. They go through the motions of sprint planning but they just each plan their own work and pre-assign work to themselves. There is no shared sprint goal – each person has a story or two and that is their focus for the sprint. If this is the case, why bother with a Daily Scrum? Pre-assigning work obviates the need for collaboration and teamwork. Stop doing the daily scrum meeting!

Root Causes of these Issues

Most of the issues above have nothing to do with the daily Scrum and everything to do with a lack of understanding of how to use Scrum.

  • Lack of skillful facilitation by the Scrum Master
  • The Development Team is not empowered, trained or coached properly
  • The organization is A.I.N.O. – Agile in name only. People still do what they did prior to Scrum adoption but now use Scrum Terms for it.

What Does the Scrum Guide Say about the Daily Scrum?

Here is what the Scrum Guide says about the Daily Scrum:

The Daily Scrum is a 15-minute time-boxed event for the Development Team.

Every day, the Development Team should understand how it intends to work together as a self-organizing team to accomplish the Spring Goal and create the anticipated increment at the end of the Sprint.

The structure of the meeting is set by the Development Team and can be conducted in different ways if it focuses on progress toward the Sprint Goal.

Daily Scrums improve communications, eliminate other meetings, identify impediments to development for removal, highlight and promote quick decision-making, and improve the Development Team’s level of knowledge. This is a key inspect and adapt meeting.

Note: The quotes above were actually taken from The Scrum Guide Reordered, a topic-centric rewrite of the Scrum Guide by Stefan Wolpers. Wolpers created the reordered guide to help him prepare for the PSM III certification. You can download your copy by registering for the Age of Product newsletter.

What You Will Save When You Stop Daily Scrum Meetings

Here is a shortlist of the savings you can expect when you stop wasting time in the Daily Scrum.

Team member time = $50-$100K per year

The biggest cost savings will be time spent by your Dev Team members in the Daily Scrum. Depending on how long you currently spend (waste) each day on the daily Scrum, you can save at least 75 minutes a week (5X15) per person, or even more. An average team of 7 developers will save about $1,000 a week at a minimum which is $50K a year. Those who are doing 30-minute daily scrum meetings can save $100K which is probably enough to pay for another full-time equivalent. In other words, rather than meet daily, use the money to hire one more developer per team.

Other’s People’s Time = $5,000 per person per year

If others attend your daily scrum meetings, that will save their time as well. This could be the Scrum Master, Product Owner, Project Manager, Dept. Manager, and any other interested parties. For the well-run Daily Scrums (those kept to 15 minutes), that is a savings of 75 minutes per week or 60 hours a year. That is likely to be at least a savings of $5,000 per person or more.

Scrum Master / PM Admin Time = $5,000 per year

If you have a Scrum Master acting as the team administrator they will save the time to attend and then capture the notes and email them out. In addition, team members don’t have to manually delete the email that they receive with the notes from the daily standup. And managers won’t receive, read and react (or overreact) to the notes from the daily scrum. Team members won’t waste time getting pulled into meetings with managers to clarify things or answer questions about things managers read in the notes that came out of the daily scrum.

Or if the Scrum Master is also the Jira Lackey, they can save the time that they are moving stories or subtasks in the tool. Though my guess is that your tool jockey will continue to do this activity anyway, even though they aren’t having a Daily Scrum.

Increased Morale and Engagement

Most developers dislike meetings, especially those where they are going to be talked down to or berated. Imagine how much better developers will feel if they aren’t told what to do or if they actually feel empowered to self-organize.

Are there other possible savings from eliminating a poorly run Daily Scrum?

Related Posts

By Anthony Mersino

Anthony Mersino is the founder of Vitality Chicago, an Agile Training and Coaching firm devoted to helping Teams THRIVE and Organizations TRANSFORM. He is also the author of two books, Agile Project Management, and Emotional Intelligence for Project Managers.


  1. You are a genius dude !!!

    This shit, the daily standup, is like having a daily weekly status meeting.

    By that I mean, before we had only 1 status meeting per week. Now we have 5 per week. I can’t stand the daily status standup meeting

  2. Scrum is bullshit programming methodology shoved down the throats of developers by idiot managers who don’t know jack about coding. The whole methodology should have died long time ago.

    1. Welcome Reddy, thanks for your comment. I think you meant “shoved” and not “showed”, and I agree that shoving does happen quite a bit. Your sentiments are similar to what Jared Richardson called Weaponized Agile back in 2015 and Ron Jeffries called Dark Scrum back in 2016.

      Just to clarify, the creators of Scrum call it a framework. You may consider it bullshit, but it isn’t a “programming methodology”.

      Keep poking around the site I bet you find a bunch of posts to comment on!

  3. I find the daily scrums to be a waste of time. As the author said, these are used for the manager to get daily status updates to report up the management chain and to press people to work faster. Also as the author said, developers generally are working on individual stories assigned to them and a developer’s status is meaningless to other developers. Most companies now have a chat channel where people can post questions if they get stuck or are blocked. In the scrum, if you have a blocker, you are supposed to resolve it offline anyway. The other issue is that developers feel like they must “justify” their time since the last meeting and some will go on and on giving every detail in resolving something. I’ve seen instances where a developer will talk for 20 minutes! Given the use of chat channels now, I think having daily meetings to keep developers connected, is obsolete. While they do have some value (and some devs love the meetings), I think the staff hours burned are not providing value to the company.

    1. Hi Dean, thanks for your comments. I think people mis-using the daily Scrum would be better off not doing it for the reasons mentioned and including yours as well.

  4. I also don’t like the idea of arbitrarily breaking ALL work up into stories that must fit into a predetermined scrum cycle. Breaking up work and merging to mainline as soon as possible is good. But requiring all work for revolve around 2 or 3 week scrum cycles is a bad idea. Its fine for IT departments or developers fixing software bugs (both are essentially the same). But for new software development, I don’t think its a good fit.

  5. Any organizational framework used to align work towards a common goal can be misused and abused by poor leadership. This isn’t unique to SCRUM/AGILE and it’s certainly not unique to the daily stand-up. If a company is unable to follow the tennant of a daily stand-up we shouldn’t just be telling them to stop the daily stand-up meeting, they should stop calling what they do SCRUM/AGILE, because it’s not, it’s AINO. I really think most developers who hate SCRUM/AGILE are living in one of those situations where SCRUM/AGILE is misused or abused. Let’s remember, the whole framework is about empowering development teams to self-organize and remove themselves from the tyranny of middle-management insanity. It’s also not a framework that a lone-wolf developer is going to enjoy or support, but I see that as an added value.

    1. Jay, I could not have said it better. Keep coming back and add your voice to the discussion!

  6. I would like to support what you are doing here, please keep the conversation going. And maybe the CEOs and CIOs will notice it. Because in practice, the theory of Scrum or any well-intended work (or economy) management meets the agency problem (ref. to Jay’s “middle-management insanity”, kudos). In practice, Scrum almost always backfires unless the officers and owners of the company watch the corporate culture like hawks their own nest. Any statistics to the opposite drawing a picture of a Scrum miracle seem to be just advertisement. Major corporations in IT industry who used Agile before it had a name, have never adopted and will never adopt Scrum. And the ones who have, are well known for their very bad quality of products and lack of innovation. From a more technical perspective – what makes Scum a failure in practice: 1) It offers “rules” or a “recipe” (some call it guidelines, but it is not how it they are treated in practice) – these allow to grab onto and twist, spin, purport, and “customize” it in any way they like and then pretend, or just say “look, I am doing it by the book” (or the way our consultants say). On the other hand the Agile Manifesto is written like a Constitution and your management practice either follows the spirit of it or, well, not; 2) The BuZZ, that drives everyone crazy and forces poor people (including business people) to use (eat) it whether they want it, need it, or not. The pressure starts with the investors, with all levels of bureaucrats, government or corporate alike, …but a quick and ready “indulgence” for this pressure is right there, it is easy, it is formalized – just give some people and some meetings some names, declare it Scrum, and then run it through Jira ticketing assigning work without ever seeing or talking to the developer. Bottom line: Aim Agile consulting at the corporate management, officer level (CEO, CIO, etc. and/or other people who do care about the “bottom line”) and relate it to the corporate culture; show corporate leadership what’s at stake and what might happen if they are not actively involved.

Leave a comment

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.