I have a daily standup meeting with about 20 people. I only work with 2 of these 20 people. When it is my turn to stand up, I say what I've done and what I will do; it takes me about a minute. For the rest of the meeting, which takes anywhere between 15 min to 1 hour, I sit there pretending to listen to what others are saying about topics I am not working on and are not relevant to me.

This isn't to say I am not involved with those two people I work with. We usually talk before the meeting to "sync up" we let each other know if we have an issue. If someone is waiting on me, I tell them what I'm up to, and so on. We do this whenever it is needed. If something comes up, we don't wait for the following day to come along for us to "speak up" when we have an issue. We talk then and there, and we usually fix the problem or plan how to fix it long before the next daily meeting.

This got me thinking about why we are doing the daily standup. According to Scrum guides, the daily meeting is supposed to focus "on progress toward the Sprint Goal and an actionable plan for the next day of work" and to "promote quick decision-making."

Still, the guide goes on to say that devs "often meet throughout the day for more detailed discussions about adapting or re-planning the rest of the Sprint's work." So this is what I find myself doing.

If quick decision-making is what the daily is supposed to be for, well, this is what my colleagues and I do throughout the day. Whenever something comes up, and we need to make a decision, we immediately "sync up," involve whoever else needs to be involved, and decide then and there what to do. What, then, is the point of the daily?

  • The reason you need to hear what others are working on and/or have trouble with is if you can help them you can speak up and save time for the project If that doesn't make any sense, then the meeting have too many attendants and should be split into separate meetings. Commented Mar 12, 2022 at 12:48
  • 2
    Well, by this logic, we should have a meeting with all 10k employed devs in the company just in case someone has a problem that someone else can help with. Commented Mar 14, 2022 at 9:34
  • Don’t be silly. Haven’t you ever worked on something a colleague could have helped you finish faster if you had just asked? Commented Mar 14, 2022 at 10:21
  • 2
    It's one thing to ask for help, and it's another thing to go asking people if they need help. When someone asks for help, the act of helping is a reaction to that initial plea for help, whereas actively waiting for someone to ask for help knowing that no one might is... well, a waste of time, especially when those that might ask you something are working with completely different technologies on different projects. Sure, you might be able to give some general advice, but you won't be able to solve the issue. Commented Mar 14, 2022 at 11:26
  • 1
    I think I misunderstood your initial comment. I thought that you were saying I should hear what all my colleagues, including those that I don't work with, which is most of them, in the event that I may be able to help them somehow. Commented Mar 14, 2022 at 16:52

6 Answers 6


There's a difference between a Daily Scrum and a standup meeting.

The Daily Scrum is one of the Scrum events and is defined in the Scrum Guide. It is a 15 minute event for the Developers of the Scrum Team to look at their progress toward the Sprint Goal and determine what they will do over the next day to move closer to achieving that Sprint Goal. It's a planning event held by and for the Developers, managed by the Developers, and perhaps facilitated by the Scrum Master upon the Developers' request.

In agile software development, the daily standup meeting originates from Extreme Programming. It includes the entire team - the developers, the onsite customer, the coach, and anyone else involved in the day-to-day work. Originally, everyone did stand to keep the meeting short, but that rule has been put aside by many teams. It includes both status update and planning components.

Outside of agile software development, other types of teams have used similar practices to update and align the team.

What you describe as a "daily standup meeting" - a meeting that could run upwards of 1 hour with 20 people that includes topics not related to your daily work - does not align with Scrum's definition of a Daily Scrum or Extreme Programming's daily standup meeting. For me, the two biggest concerns are the number of people (20 is much too big for an agile software development team) and the topics (topics should be directly relevant to all of the people in attendance).

In theory, the purpose of Scrum's Daily Scrum is not to make fine-grained decisions. The guidance about meeting throughout the day often includes solving the most specific problems faced by the team and often includes a subset of the team. When you start including all, or even the majority, of the team's Developers in either decision points or perhaps in all of the work, you are moving toward mobbing, and the Daily Scrum becomes less useful. The Daily Scrum is most useful when people are working in individuals or pairs and need to have an opportunity to synchronize, make sure that their Sprint Backlog is reflective of reality for external stakeholders, and if there are any risks or impediments, involve the Product Owner and Scrum Master immediately.

You may see some value in you and your direct colleagues meeting for up to 15 minutes once a day to carry out a true Daily Scrum. In some cases, this may replace some of the more ad-hoc "sync ups" that you are doing and give the individuals more time for focused work with less interruptions and context switching. However, there's really no problem with the ad-hoc sync ups if the team is satisfied with their performance. It may not be Scrum, but being an effective and efficient team is more important than following the rules of Scrum.

  • 1
    The takeaway regarding the scrum meeting is that only relevant people should participate and synchronize, but regarding the actual necessity, why do you say that the ad-hoc talks are interruptions? If I, as a frontend developer, notice that an error occurs when I make a request to the backend that my colleague is working on, should I wait for the next day to let him know? Or if I notice a flaw in the business logic we are implementing, should I not contact my colleagues to discuss it? By the time we finish with all the talks, we already know what each of us is doing and what we plan on doing. Commented Mar 10, 2022 at 11:49
  • 1
    @user1969903 Yes. Nudging them and asking them to look at something is an interruption. Even if they don't look busy, they could be working - reading something relevant to their current work, thinking through a problem. Unless they are taking a full-on break from work, asking someone to look at a problem is an interruption and requires them to shift their focus into what you need and then shift it away after. Having a good Daily Scrum is a great way to let everyone know what you are working on and if you anticipate needing someone else's knowledge, expertise, opinion, or just eyes on work.
    – Thomas Owens
    Commented Mar 11, 2022 at 19:33
  • 1
    @ThomasOwens If anything, I've added two more interruptions to the mix because now we have: 1. daily where the issue is mentioned briefly (but I guess this was mandatory anyway), 2. separate meeting to discuss it in detail; 3. The actual time where the issue is looked at. How is this different? By the way, I am talking about issues that are relevant to and need to be fixed in the current sprint. Anything else would be part of a future sprint. Commented Mar 13, 2022 at 7:52
  • 1
    @user1969903 Having a planned interruption is better simply because its planned. Taking 15 minutes to decide on what's important and when the necessary people can get together is a whole lot better. Perhaps it's not even today - perhaps the people can resolve the problem tomorrow or the day after. You have natural context switches between tasks anyway, so you're planning and taking advantage of those instead of having arbitrary context switches in the middle of the work. It helps to maintain focus and flow to be able to set aside the time to finish a task or prepare for the context switch.
    – Thomas Owens
    Commented Mar 13, 2022 at 15:00
  • 1
    @ThomasOwens I guess what it boils down to is what constitutes an interruption and if they are as costly as you say they are. If that's the case, then every non-work email notification, slack pop up, calendar reminder, etc. are each wasting up to 15-20 minutes of work. I get about 20 of those a day (roughly 8 emails/day, the rest just random slack / teams chats) for a total of up to 5 hours lost to context switching. That surely isn't the case. Why? Because I can ignore them, especially when I am concentrating on something. I know they're there, I can get back to them when I feel like it. Commented Mar 14, 2022 at 11:50

The Daily Scrum meeting is there to align between the people who are actually involved in working towards the Sprint Goal.

It is supposed to be short and not go into detail. It indicates who needs help, who is working on something that might interfere with your work; Daily alignment is key.

It is not a daily progress report. It is not reporting information that is not immediately needed by that group of people. And it is not a meeting hijacked because it is so convenient to have everyone together.

If your description is accurate you guys are wasting 10-20 working hours a day. My suggestion would be that everyone writes a brief note indicating what they bring to the meeting and what they get out of it. That takes two minutes and the results should help to restructure the meeting.

  • I agree that the meeting we are doing is not exactly constructive, but that is not the main focus of the question. What I am asking is why do we need a daily meeting if we already have short meetings where the relevant people are getting aligned whenever the need arises which, in reality, happens several times a day? Commented Mar 10, 2022 at 11:37
  • 1
    So you have a working routine where you speak and align frequently during the day already. In that case a daily scrum for the three of you would be a meeting where you step back for just a moment, do a quick overview and then go to work. Compare it it a restaurant kitchen; during work you would be tied up in the details of the dish you are making. The scrum is where you look around: are there still enough vegetables, how many orders do we have tonight, is anything of interest that you will run in to later on - like a large party at 20:00. It's a day-planning and it can be over in minutes.
    – ErinH
    Commented Mar 10, 2022 at 11:49
  • 3
    Addtion: You may note that you do this alignment with your collegues during your day, and you don't need a separate meeting. Scrum is not hung up on form; that just means you have found a form that works for you. The Daily Scrum is a reminder that the alignment is needed, and the Standup is a form that works for many people.
    – ErinH
    Commented Mar 10, 2022 at 12:02
  • Sure sounds like a "daily progress report" to me. Sounds like something that could be replaced by a quick glance at a Jira board. Commented Jul 26, 2023 at 16:29

It seems to me that your meetings are mislabeled: The 1 hour plus sit-down meeting with 20 people, most of whom neither affect nor are affected by your work, is not a Daily Scrum.

The Daily Scrum is this:

This isn't to say I am not involved with those 2 people I do actually work with. We usually talk before the meeting to "sync up", we let each other know if we have an issue, if someone is waiting on me I tell them what I'm up to and so on.

This simple chat with your direct collaborators, so brief that it doesn't even require sitting down, is a Daily Scrum. And since you have invented this tradition all by yourself (a self organizing team!) you already know the value this meeting brings to your day.

Appendix: Why is your long meeting not a Daily Scrum?

Scrum is defined in the Scrum Guide, which writes:

The Daily Scrum is a 15-minute event

... and that's a time box, i.e. if the team feels the meeting is done earlier they may of course leave earlier.

for the Developers of the Scrum Team

... so only the developers, not the entire team. And even the entire team should be

small enough to remain nimble and large enough to complete significant work within a Sprint, typically 10 or fewer people. If Scrum Teams become too large, they should consider reorganizing into multiple cohesive Scrum Teams, each focused on the same product.

If you only need to coordinate with two others the 3 of you should be your own team, with your own meeting!

And because Scrum Teams are

self-managing, meaning they internally decide who does what, when, and how.

the team gets to decide how it runs its meetings (possibly coached by the Scrum Master, who serves the team by

Ensuring that all Scrum events take place and are positive, productive, and kept within the timebox.

So if your Scrum Master was any good, they'd prevent hour long daily meetings full of irrelevant info ...

Appendix 2: Why daily?

Why do we need a daily meeting if we already have short meetings where the relevant people are getting aligned whenever the need arises

What distinguishes these short meetings from a Daily Scrum?

That the people involved are relevant? Like any meeting, the Daily Scrum should focus on topics of interest to its participants. Topics that affect only a small subset of participants should be discussed elsewhere (in this case, the Daily Scrum can still be useful to figure out who should be involved, and when to meet). Moreover, since Scrum teams are supposed to be cohesive, your work should usually be relevant to the rest of the team, so there should usually be something to talk about. And in the rare cases where there isn't, you can end the meeting early.

Or is it that the meeting is whenever the need arises? That can be a blessing and a curse. A blessing, because the meeting happens only when needed, but a curse, if a new meeting happens every time a need is identified! After all, every meeting interrupts the participants, causing information relevant to whatever they were doing before to be evicted from short-term memory, which will take some time to reconstruct before the work can proceed. By gathering these discussions in a single meeting, several topics can be discussed at the cost of a single interruption. And by having this meeting in the same time and place every day, scheduling is greatly simplified.

So why daily? Because that's easy to remember, and happens to be a good trade off between immediacy of discussion and frequency of interruption for many teams.


First off, as others have mentioned, what you describe first is not a daily scrum standup meeting. What your company is currently doing is what people who are way too used to linear or non-agile methodologies usually do when they want to say they've adopted an agile methodology without actually changing anything; so the only purpose of that current meeting is to let the managers know what everyone is working on and what percentage of work is completed.

Now, what you describe you do with your team is more like what a daily scrum or daily standup meeting should be: a quick reunion to sync up the work of all the members, find out if there's anything that needs to be discussed or escalated, and decide on how the work will flow until the next meeting.

But! as you mention, some of this can (and should) be worked out or discussed during the day; this is precisely the reason why the daily meeting has somewhat been refined/redefined/repurposed through time. If there's still a daily meeting in the scrum guidelines, it's because an agile methodology is supposed to be, well, agile, and not every issue, obstacle or problem is worth suddenly stopping the work of other members of the team to discuss it. Sometimes when something comes up, you just need to register it on whatever tool is used as backlog, pick up the next task, and then let the team handle it during the next daily meeting.

It might seem that the scrum guide contradicts itself on these topics, but let's not forget that scrum is a framework and not a set of rules carved in stone. For some teams/organizations the daily standup is enough, for others meeting during day is more efficient, for others it might be a combination of both; after all, one of the scrum objectives is to have self-organizing teams that are able to find what works best for themselves.

So, if meeting both during day AND before that other larger meeting is working for your team and complies with the guidelines of your company/department, keep doing it. If your position allows you to raise your concern that the larger meeting is distracting or can be improved, do it too. Remember that there should also be a retrospective meeting where this kind of issues can be addressed.

  • "If your position allows you to raise your concern ..." I think that sums up pretty nicely why cooperate culture and agile/scrum is, let's say, a difficult fit at best! Commented Mar 11, 2022 at 21:31
  • Thanks for your take on the issue. We do have a retrospective, but we have it mostly just because it's part of our contract. Nothing really gets done. At least, that's how I feel about it. I never heard anyone following up on a previous issue and saying that the problem from our last retro was fixed. If anything, I hear that the same problem still exists. Commented Mar 13, 2022 at 8:00

Where I work, we don't do everything exactly by the book. But the Daily Scrum is a place to:

  • Mention the schedule for the next 24 hours, when that affects others.
    "Almost finished with that story. I'll need another Dev for the merge request. Who is free?"
  • Mention possible impediments, and find out who needs to talk about them.
    "I don't think the UX works as we hoped. We should look at it with Design and Product Owner. Tomorrow afternoon?"
  • Give the Product Owner or the Devs a chance to change the sprint.
    "That bug just came in. It is/isn't more important than the sprint goal." Or just "One of you look at it and give a rough estimate. Who?"
  • Advise the Product Owner and Scrum Master about the state of the sprint goal.
    "We underestimated that story. We'll need to drop something else if you want to get it done this sprint."
  • Socialize a little bit, especially since we're still doing home office under pandemic rules.

A dozen people, 15 minutes. On a good day, 10 minutes Works out to less than a minute of speaking time for most. It is a place to delegate or escalate problems and to schedule non-routine meetings.


The Scrum meeting is an essential part of every project’s management, especially one following Agile methodology. It’s considered a valuable source of getting real-time updates, information, and feedback from the development team. It also serves to help keep the field team aligned with the company’s goals and deadlines.

To take full advantage of the benefits of daily Scrum meetings, companies need to believe in empiricism and create an integral framework for implementation. If you, your team, or your Project Manager isn’t convinced yet, let me help! Listed below are many benefits of implementing daily Scrum meetings for successful teams, organizations, individuals, products, and services.

  1. Increased Collaboration and Ownership
  2. More Relevant Metrics
  3. Improved Progress Visibility and Exposure
  • No offense, but you sound like one of them evangelists knocking on people's door asking them if they heard of the many benefits of "our lord and savior, [insert politically correct, woke, gender neutral deity]". Commented Mar 16, 2022 at 9:17
  • This doesn't seem to address the question that was actually asked. Commented Mar 18, 2022 at 12:51
  • Hello? ChatGPT? Commented Jul 26, 2023 at 16:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.