I used to work in a waterfall methodology and now I am in a team that is following an agile methodology. It seems they are doing it wrong. For example, we have stand-ups that last 25+ minutes daily, which is really annoying. Additionally, I feel more like I am justifying my salary to management than anything else.

Am I wrong to feel this way? Is this how stand-ups are usually conducted?

  • 3
    Have you suggested during the Retrospective that the stand-ups are too time-consuming? What's discussed during the meeting that takes 25 minutes?
    – dcaswell
    Sep 8, 2013 at 17:11
  • How many people are on the team?
    – Guy Sirton
    Sep 8, 2013 at 17:14
  • 1
    @GuySirton:I understand what you are saying but on the other hand aren't ~30 mins each day gone?Isn't this too much?
    – user10326
    Sep 8, 2013 at 17:37
  • 1
    Down vote and no explanation....
    – user10326
    Sep 8, 2013 at 17:37
  • 2
    @user10326: Your management obviously doesn't think it's too much. Assuming they make the rules (it varies between companies) and you can't convince them it's too long then it will be 30 minutes. You're almost certainly not going to convince them by referring to Programmers or the Scrum Manual. How to deal with the team/work situation is perhaps a question for Workplace SE. Here we can tell you about how it's supposed to work but not sure we can help you with your specific situation.
    – Guy Sirton
    Sep 8, 2013 at 17:43

4 Answers 4


For Scrum, Ken Schwaber and Jeff Sutherland explain:

Daily Scrum

The Daily Scrum is a 15-minute time-boxed event for the Development Team to synchronize activities and create a plan for the next 24 hours. This is done by inspecting the work since the last Daily Scrum and forecasting the work that could be done before the next one. The Daily Scrum is held at the same time and place each day to reduce complexity. During the meeting, the Development Team members explain:

  • What did I do yesterday that helped the Development Team meet the Sprint Goal?

  • What will I do today to help the Development Team meet the Sprint Goal?

  • Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal?

The Development Team uses the Daily Scrum to inspect progress toward the Sprint Goal and to inspect how progress is trending toward completing the work in the Sprint Backlog. The Daily Scrum optimizes the probability that the Development Team will meet the Sprint Goal. Every day, the Development Team should understand how it intends to work together as a self-organizing team to accomplish the Sprint Goal and create the anticipated Increment by the end of the Sprint. The Development Team or team members often meet immediately after the Daily Scrum for detailed discussions, or to adapt, or replan, the rest of the Sprint’s work.

The Scrum Master ensures that the Development Team has the meeting, but the Development Team is responsible for conducting the Daily Scrum. The Scrum Master teaches the Development Team to keep the Daily Scrum within the 15-minute time-box.

The Scrum Master enforces the rule that only Development Team members participate in the Daily Scrum.

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.

Other methodologies may have different rituals and even different Scrum teams may optimize the way they do this differently. The key idea is a quick get together to make sure the team is on track to deliver. It should not be a management status report. It is however one of the agile ideas that is more easily subverted.

  • There is also a web based stand up meeting that we are using for our daily standup if it helps somebody: standup.report
    – MagExt
    Aug 14, 2015 at 2:21


When properly executed within an appropriately-sized Scrum team, the daily stand-up should never take more than 15 minutes or so. If it takes longer, either the team is too big or you have a process problem.

The Purpose of the Stand-Up

The daily stand-up is a commitment and coordination meeting for the entire team. It is designed to ensure that the entire team is aware of impediments, what stories are done or not-done, and what tasks are ready to be pulled from one team member's to-do list into someone else's.

It's important that the Scrum Master and the Product Owner be active participants in the stand-up, but if the team is reporting to either of them then your Scrum process may be well and truly broken. A related answer on Project Management Stack Exchange has a 10-point list of "project smells" at the bottom, some of which may apply in your case. Even if they don't apply, you should definitely re-evaluate the effectiveness of your stand-ups at your next Sprint Retrospective.

Respect the Time-Box

While I dislike the "three questions" as a concrete format precisely because they tend to lead to meetings that resemble a status pull, I'd be remiss if I didn't point to Mike Cohn's canonical description of the Daily Scrum. The page says, in part:

By focusing on what each person accomplished yesterday and will accomplish today, the team gains an excellent understanding of what work has been done and what work remains. The daily Scrum meeting is not a status update meeting in which a boss is collecting information about who is behind schedule. Rather, it is a meeting in which team members make commitments to each other.

There's a lot more detail and some concrete examples on that page. However, for the purposes of your question, it is explicitly stated that:

Scrum daily standup meetings are strictly time-boxed to 15 minutes. This keeps the discussion brisk but relevant.

The time-box is the foundation of Scrum. While most time-boxes within Scrum can be adjusted by the team as a result of the inspect-and-adapt cycle, it is considered poor practice to extend the length of the stand-up. If the time-boxing principle isn't being respected within your process, that's generally a very whiffy "project smell."


As with all Agile processes this the purpose is: "what you get value out of".

The daily standup is typically a mechanism for ensuring communication between team members in a low-impact way, where everyone can understand where the team is with regard to the current set of tasks. So a 5 minute standup where everyone says "I did x yesterday and I'm going to do y today" is fine, as is a 15 minute one where the team decides between themselves what to work on next and updates the task board.

However, there's no need for one at all, not if you communicate these things in other ways, say using a rolling social notification system, for example.

Similarly, if you want your standup to be longer and more of a team reporting thing, then that's fine too. I'd question it, but I know some teams prefer a more directed approach to being given work. Agile can cope with all types of team after all.

The real question you should be asking is whether you are getting any value from it, and if not - what will you change it to be so you do get value. Doing the standup as prescribed by some holy book of Scrum is NOT Agile. Doing a standup that means something to your team so that you all work together better is.


What you are describing is one way in which 'stand-ups' can fail for the team.

The best stand-ups are short because everyone understands what everyone else is doing, they explain what they achieved yesterday, what they will achieve today and flag up anything that may/did affect their ability to deliver on their promises. Other members of the team can then indicate that they can help solve each others impediments quickly, but that solutions take part outside of the stand up.

In short, They should be the glue that binds the team together.

What it sounds more like, is a status update, and you being held to account for delivery/not delivery, but the team is dysfunctional because the team are not using the stand up meetings to support each other to deliver and to remove the impediments.

In the two environments that I have seen this occur, its been caused by having a scrum master who has failed to delegate the responsibility of ensuring the team deliver on their iteration promises. In one case it was particularly counter productive and generated an us/them attitude within the team.

Scrum is about self organising teams, where the team organises itself to solve problems quickly to deliver on their commitments


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