My understanding is that a Daily Scrum meeting should be very quick, hosted in a friendly way and that it requires all the team members present. Because it is objective is to have everyone up to date with what everybody else is doing.

I like Scrum Daily Meetings that are held like that.

In my latest project our Daily Scrums are more like a Status Update meeting. Although the position is that we are holding Scrums and practicing proper Agile.

We are a distributed team, in 2 different countries, and the people that is in the same Country are not in the same office. As consequence we have virtual Scrums.

The problem is that our meetings always start on time, many people calls before the actual start time, so they actually start at the very first second of the meeting. Without any tolerance for small delays.

For example the last time we were on the phone and the person coordinating the meeting checked if everyone was on, and we said one of our team members was not on yet but he was calling. And I was told to start sharing without waiting for my team member.

Also everyone has a lot of meetings, and sometimes they are back to back with the Scrum meeting, so it is understandable if they arrive during the first or second minute of the meeting.

Is that the normal for teams practicing Daily Scrums? It is the first time that happens to me.

I can not find any bibliography directly about it. Although the presence of all team members is stressed, it is stressed also that the meetings should always start at the same time. But I imagine there can be a small delay tolerance.

I even read on a blog someone suggesting that the Scrum Master can place penalties if someone arrives "5 seconds" late. I thought the Scrums were supposed to be friendly, and having a penalty like that seems counter productive.

What is the recommended approach in a situation like this?

  • If you have a scrum with 11 people and 1 guy us 1 minute late, that's a waste of 10 minutes of company time. If 1 guy is 6 minutes late that's already an hour. Something which may seem small may turn out to be surprisingly big.
    – Pieter B
    May 20, 2017 at 8:17

5 Answers 5


Like with any agile practice, scrum teams can decide this for themselves. If it bothers you, you should bring it up in your retrospective and try to come to a solution that everyone is happy with. Perhaps other team members feel the same way, but think that's "just how scrum is done."

That being said, in my scrum meetings I start on the second unless three or more people are missing. For a meeting that everyone is required to attend every day, I feel it is disrespectful of everyone's time to do otherwise. When I'm the one that shows up late, my team starts without me. If we have time at the end, we go back to the tasks of people who came late.

I have been less strict about punctuality in the past, and what happened is people who showed up on time got tired of their time being wasted, so they started trying to guess when the meeting would actually start, and show up then instead, which had a snowball effect.

For a daily meeting, it's not the end of the world if someone occasionally misses part of it. Hopefully it isn't the only communication you're doing throughout the day.

  • I get your point. Although I feel that it sort of breaks the spirit of the Daily Scrum, at least as it is described. Plus it has never been a delay more than a minute. And it is mostly, because the Software doesn't work well. The usual teleconference issues.
    – Sky
    May 7, 2014 at 20:35
  • 2
    It's a lot easier in person as generally people are seated near each other, and can be grabbed if they are late. I am product owner on a project that sounds similar in that we have people working in at least four separate locations internationally. It is more difficult because sometimes people are "late" due to technical limitations. I personally think a balance can be made if people aren't abusing it. May 7, 2014 at 23:05
  • @StevenBurnap That is what I feel, no one in my team is close. And that a meeting start hour is 3pm, doesn't mean people start talking at 3, it means they get together at 3. I just feel being so strict is actually counter productive in distributed teams.
    – Sky
    May 8, 2014 at 17:56
  • I vote this one because you said first that the Scrum teams can decide it for themselves, and that you mentioned some people may feel "that is just how scrum is done". The rest is relative, as the conditions for each situation are very hard to explain over here. And regarding punctuality, it depends on the people, I rather not punish people that honestly had issues, just for the future possibility of abuse, since distributed teams have additional complications that I can't describe here. Thanks for your answer!
    – Sky
    May 15, 2014 at 14:17
  • 1
    except that in the real world the team doesn't always take responsibility and it's a manager or half-manager who takes control of the meetings and forces them and enforces the rules.
    – user7433
    Mar 7, 2015 at 16:51

If you wait for people, it teaches them it's OK to be late. If you start on the minute, people will be taught they need to be there on time if they want to participate. Programming is a professional activity that requires at least a modicum of discipline.

That being said, the point of the daily standup is to discuss what the team did yesterday, what they are doing today, and to make everyone aware of roadblocks. The scheduled time should be "first thing in the morning when everyone is available", not necessarily a specific time on the clock. The end goal is to work together as a team, not follow strict rules. If your team is very new to agile, sticking to the clock is good way to build your team skills. If you're a mature team, do what works for your team.

  • Only problem with "first thing in the morning when everyone is available" is that there isn't the rhythm obtained from doing it at the same time everyday. It also doesn't allow the later arrivals time to get engaged with work and catch back up so they won't forget anything in their daily scrum. I think your point about starting with no delay is a good one! It teaches everyone to be on time. That is an excellent point and one I will suggest we adopt.
    – jmort253
    Jul 9, 2015 at 9:15
  • 1
    I guess I wasn't clear enough. I didn't mean a different time every day. I meant that the team has to pick the earliest time that they are all available, and then they should use that same time every day. Jul 9, 2015 at 10:09
  • Oh. OK that makes perfect sense then. Glad I asked. :)
    – jmort253
    Jul 9, 2015 at 12:18

People over process. That's one of the core tenants of Agile, if a process isn't working for your team, scrap it or modify it. Let the team modify it to fit their needs.


Is this how Scrum works?

I would suggest to you that daily meetings are too often for any business activity, unless your team is especially productive (meaning they can produce large swaths of functionality in very short time periods).

If you do decide to have daily tag-ups, they should last no longer than 15 to 20 minutes, and yes, everyone needs to be on time or they don't participate. Tag ups are for the benefit of the team members, not the scrum master; penalties for missing daily meetings should be handled in the same fashion as any other tardiness would.

In short, I don't see anything special here. I do think that daily meetings of any kind border on micro-management, but if you do decide to do them, you need to do them properly.

  • 1
    Isn't the main objective of having an unstructured meeting every day that the team can know what everyone is doing and offer help to others? And therefore it is more important that they are comfortable and share, than if they arrived 30 seconds late?
    – Sky
    May 7, 2014 at 20:28
  • 3
    if you know they are calling in, why not wait? -- Because a 3 minute wait becomes a 5 minute wait, then a 10 minute wait... As Tom Hanks eloquently said in the movie Cast Away (when discussing the on-time record of Federal Express) "Before you know it, we're the United States Postal Service." May 7, 2014 at 20:40
  • 2
    If you don't maintain punctuality, people get annoyed with you and with each other. If you maintain punctuality, people get annoyed with themselves for not making sure they were ready. Which would you prefer?
    – keshlam
    May 8, 2014 at 1:57
  • 2
    I think 15-20 minutes is way too long. If you're going more than 5 minutes you're doing it wrong. May 8, 2014 at 2:52
  • 2
    @RobertHarvey the purpose of the daily scrum is to very quickly take the team's pulse, identify impediments, and schedule follow-ups between only the necessary team members as necessary without wasting everyone's time on a longer, more traditional meeting. See en.wikipedia.org/wiki/Stand-up_meeting#Software_development for a nice overview. There is a lot of literature available on scrum and you may find that reading some of it helps you better understand scrum questions and puts you in a position to provide more meaningful context-specific advice.
    – rob
    Feb 18, 2015 at 17:05

Think of it like this, what is the point of the daily stand up?

It is your opportunity to raise impediments with the rest of the team, to flag up that you may need assistance, and to highlight changes that will affect others. It is important that you as a developer are there.

With a team of 4 -8 developers, they need to be quick and snappy - 30 seconds each most of the time. If was performing the role of scrum master, I would be concerned about late starting of the meetings as it would increase the meeting cost. Likewise, variable meeting times create a distraction for everyone - are we about to... I would also be very aware of balancing this with the needs to ensure the team is able to support each other, so may delay the meeting if needed because someone who was likely to be impeded was on the telephone / toilet.

Where teams are distributed geographically like you are describing, I would be flagging this up as a team impediment at EVERY retrospective. It is blatantly an impediment to the scrums performance and communication that they are not all sat together and able to communicate freely and easily.

I would be arguing that this should be organised as two separate scrum teams, and work organised so that scrum of scrums should handle the international communication.

  • As it turned out, and as it was my feeling, the issue was not with the process, was with the people. They were using the process as an excuse, as the team members got more acquainted with each other, tolerance grew, and all of the sudden they didn't have a problem waiting 30 secs or a minute for someone to join, because now they knew each other. I wouldn't advise to hold separate SCRUMs unless both teams work in very different parts of the project and never need to interact. I agree, SCRUMs need to be agile, but even more teams need to be cohesive and tolerant when there are issues.
    – Sky
    Mar 9, 2015 at 17:55

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.