5

For years I have been applying the suggested Scrum timeboxes with good results. Now it's my time to advise others trying to apply it. My advice is to follow the timeboxes because, otherwise, we will not have enough time to complete the job in a good way. Not only because you are borrowing time, but also because probably you're talking about too-much work for a day.

My mates seem receptive to this advice, but the following day they tend to extend it again... same for every meeting we have.

I would like to show them better evidence.

In my experience, if a Daily takes 45 minutes, you cannot expect that you will finish the work for that day and you'll have to talk about the same topics the next day, making it even worse as the date progresses. But this is just my observation.

Someone should have been studying this topic before to point out that 15 minutes (or less) will be right for a day. I mean, it was not just a whim of Agile's "founders"... or was it?

2
  • 3
    "if a Daily takes 45 minutes, you cannot expect that you will finish the work for that day" - then you should probably not commit to doing so much work on that day, if you cannot achieve that much?
    – Nico Haase
    Oct 16 at 8:32
  • We are not commiting. This causes the same 45 minutes meeting happening again. That's why I want to give a well founded reason than just "we will not finish"
    – zameb
    Oct 16 at 14:09
13

Sutherland decided to make the meeting at most 15 min long. In his own words:

[...] the meeting couldn’t last more than fifteen minutes. We wanted it to be crisp, direct, and to the point. If something required further discussion, we noted it and met further after the daily meeting. The idea was to get the most actionable and valuable information in the least amount of time.

The idea is that the daily (standup also decreases the length) should be a short point of synchronization between the team just to catch things that might have been missed by someone in the team, a team that needs to communicate and sync constantly anyways, not wait for a daily meeting to do so.

The planning should be done at the sprint planning. If the daily is 45 min long, then most likely a lot of planning is happening there, or discussion around things that should have been clarified during planning also, and previously during refinement meetings.

It doesn't matter if the daily is max 15 min or whatever, it's more important to look at the whole picture and try to figure out what's going on. The problem is somewhere else and it leads to a meeting designed to be short to take up more time.

2
  • Super answer. +1. Oct 15 at 22:54
  • 1
    I completely agree with Sutherland point of view. However, seems like an authoritative statement more than the product of some empirical evidence or the conclusion of some analysis. Interesting!
    – zameb
    Oct 16 at 20:56
4

The reasoning behind the 15 minute limit on daily scrum meetings is, as Bogdan points out, that you should never need more than that to achieve the purpose of the meeting, which is just a daily "sync" to keep everyone up to date on who is working on what and check to see if anybody needs to co-ordinate with anybody else on any of the details of what they're doing. (In my experience exceeding ten minutes should be a big warning flag; my daily sync meetings almost never take more than five mintues.)

While exceeding the time limit is an excellent heuristic to tell you that things are going wrong with a meeting, I've not found that trying to focus on the time limit works well when trying to fix the problem. Instead I suggest you focus on the purpose of the meeting, especially in convincing people to narrow that purpose, and try to help the group schedule for later things that should be done outside of the meeting. For longer meetings an agenda works well for this, but for shorter ones like sync meetings I've gotten the best results from consdering, for each point that starts a discussion, whether everybody there needs to be discussing it or whether the people who need to have that discussion can go off and do that on their own after the meeting.

For sync meetings in particular, we generally just go around the group with each person giving a sentence or two saying what they're working on and where they anticipate any major changes to the code that might affect others, taking brief questions, and then co-ordinating with others to say "here's who I will talk with later to have a more detailed discussion," if that's necessary.

9
  • I agree with all the reasoning, however, 20 minutes could be good as 10 for the same reasons. Probably we can suspect that 4 hours is to much to sync, but... once we realize that we need a time to sync every day, we still have to find which is the right amount of time
    – zameb
    Oct 16 at 20:41
  • 2
    @zameb Why ten minutes exactly? It's just a round number that's much longer than the meeting should normally be, yet still not a huge amount of time (about two person-hours for a meeting with a dozen people). Eight or twelve minutes would probably serve just as well. Again, keep in mind that this is a hueristic only to indicate a problem, a sort of warning light if you will. As described in my answer, I don't focus on time when trying to fix over-long meetings, I focus on minimizing what's done in the meeting. (The meetings becoming short is just a nice side effect of that.)
    – cjs
    Oct 17 at 3:45
  • 4
    @zameb To use an analogy: In your car, the fuel light will come on before your tank is actually empty, to give you time to get to the petrol station & fill up. Maybe in Ford cars it comes on with 10 miles worth of petrol left, in Nissan cars with 12 miles and in Toyota cars with 15 miles. The question to ask isn't "but what's the right standard for the fuel light to come on" it's "why are we so bad at regularly filling up that we continually need to depend on the fuel light to tell us to go to the petrol station". Oct 17 at 10:50
  • 1
    If you need 45 minutes worth of discussion at the start of every day, it sounds like your team needs better syncing generally across the whole of the sprint — better understanding of the spring goal, planning, task breakdown, not taking in work until it meets some 'defintiion of ready' etc. Oct 17 at 10:52
  • 2
    @anotherdave There could be problems within the general way they do sprints, but my experience with sync meetings that go on too long is usually that the problem is most often people not using them as a sync point but as the forum for in-depth dicusssions about particular issues with other developers in the meeting. E.g., instead of "Let's talk after the meeting about those tests that keep failing due to data issues," the discussion of that starts happening in the meeting itself. (And of course then the entire team has to sit and listen to it.)
    – cjs
    Oct 20 at 13:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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