Is it ever acceptable to have non-checkin-related discussions in Scrum Daily Standup meetings?

Question

I hope people will indulge me a potentially obvious question. I've worked in a number of organizations that have daily scrum meetings. Some organizations are really strict about only using the scrum for check-in (the "three questions" - what did you do yesterday, what are you doing today, do you have any blockers?) but some other organizations that tend to have other general announcements or detailed technical discussions.

I've heard the argument, such as in this article, that allowing non-checkin-related discussion like this is a mistake - the scrum meeting shouldn't be used for general announcements from the Scrum Master, technical discussion, etc.

The main harm I've seen from this is that the meetings can last longer than necessary (and it's annoying to be forced to sit in on a discussion of details that aren't relevant to me).

It's pretty clear that discussions that aren't related to the whole group and aren't part of the "three questions" shouldn't be part of the stand-up. However, if there are other announcements that are relevant to the whole group and need to be discussed anyway, is it harmful to discuss those at that point (rather than at a separate meeting or email)?

Answer 1

The purpose of the Daily Scrum is for the Development Team to review the last 24 hours, and update their plan for the next 24 hours.

Anything that achieves this goal and can be covered in 15 minutes is exactly what the Daily Scrum is for, as per the Scrum Guide. If you have longer conversations that need to happen, then just keep a running note of what they are and, at the end of the Daily Scrum, break into smaller groups that care about that topic.

What the Daily Scrum is not for is figuring out solutions to problems. Do that after...

Answer 2

Sure it is acceptable, but focus on the important things first. If we have time left in the 15-minutes, which is pretty common for a 5 person development team that is swarming (because they sync more often during development), I have no problems with extra communications and or announcements. As long we postpone them until the end of the Daily.

---

As a Scrum Master I make sure the team answers the three key questions somehow.

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.

Sometimes a short technical discussion is necessary to sync the team. As a Scrum Master I make sure we fit the 15-minutes timebox and cut-off longer discussions to be held after the stand-up.

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.

Looking from a non-Scrum and more Agile perspective. Focus on what works and what doesn't for the team. Just make sure the team decides and experiments with changes if they feel this will make them more effective and produce higher quality software.

Answer 3

Team members should keep in mind the point of the standup - that is to allow each other to contribute to issues that may take longer when kept private or within a limited circle. On the other hand, it would not be very agile to avoid issues that are important and concern the whole team but do not fit the guideline criterion stated in the Scrum pocket book. It would be stupid to schedule a separate meeting just because of a rule that is obviously meant to save time.

It may not always be clear to a speaker what his issue is. If allowing him to babble for a while will make it clear to someone else that he is struggling or following a dead-end path you may get somewhere after all. Being too much concerned with form can also harm productivity and frustrate people.

Depending on the culture the standup can be strict or include social issues as well. It should never be a mindless going-through-the-motions event that would be regarded "zombie scrum".

Answer 4

There is often a dichotomy between what various people vehemently insist is Scrum and the concept of people over processes.

If there is information to impart, ultimately it is a judgement call. If it is likely to cause a significant amount of discussion, it might be best moved to another time. If it is just something quick like server downtime etc, it can be done there and then. There will of course be shades in between in which case the scrum master should just suggest it is taken offline once 15 minutes (or whatever) has elapsed.

Either way, I'd be inclined to have it at the end after the usual standup process has completed.

Answer 5

You asked, "is it harmful?" but the other answers mostly addressed "is it 'the purpose of the meeting?'" I think those are different questions. It truly can be harmful when you sneak other agenda items onto the meeting, especially if it becomes habitual. Standups take a chunk of time every day, usually at the most productive time of day, in the morning when people have a lot of energy. You can sap that energy right out of people if they can't count on a standup being as long as necessary and no longer, and entirely relevant to them.

People will start showing up late, because they are engaged in something "more productive." They will even not show up at all some days. Other people will show up late or not all because "everyone" shows up late or not at all. The problems compound on each other, and standups stop being as useful for their original purpose. That sounds extreme, but I've seen it happen. If you do this, be very careful about where it leads.

Most teams I've been on will sometimes hold design meetings right after the standup, and that's okay if used sparingly, but honestly, I get better results if I tell my teammates at standup that I will soon be blocked needing design input and I'm going to schedule a meeting for that afternoon. That gives them time to mull over the problem as well, and after lunch people get into a bit of a slump and want a change of pace. Also, that way you don't get people competing to be the first one to have their "mini-meeting" after the standup so they can leave.

Of course, I would never advocate blindly doing something or not doing something just because some random guy on the Internet (even me) told you. Individuals and interactions over processes and tools. If you do decide to introduce some additional agenda items to your standup meetings, I would recommend to specifically bring it up in the subsequent retrospective, see if the team found it disruptive or not, and make adjustments as necessary. Ultimately, each team has a different comfort level, and will have different ideas about what is appropriate or not.

Answer 6

UPDATE: I should make clear: 15mins is the MAXIMUM time you should account for with ANY standup -- an efficient standup following the below rule is never usually more than 5mins at most and if you can distill that time down further, even better. Again, most discussion you think are relevant can easily be discussed between team members outside of the simple daily checkin process a standup is supposed to be at its most pure form.

Rule of thumb I have stuck with and drilled down during projects with friends and honed in professional setting:

• Yesterday

What you did yesterday individually to advance the project and, if relevant, that affected someone else.

• Today

As above but today

• Blockers

Anything at all that could cause one, raise alarm, no matter how trivial (means someone can come over and check your code or give you a sanity check)

Anything else is a distraction. This can mean subject that "might" seem like they're relevant to project progress are really not. It's pretty harsh but it's VERY effective for XP purposes.

Answer 7

The purpose of the stand-up meeting is effective communication. Make that your goal instead of blind-rule following. Since you've posted this question, you're on the right track.

All of your concerns are valid. Although we can attempt to anticipate if this creates any problems, I would just answer your question by suggestion you give it a try.

Avoid the following:

1. Having meetings that are too long.
2. Too many people prefer getting the announcements elsewhere. Doing it during a scheduled meeting is tempting, but don't abuse it. Most people hate bade meetings.
3. Information doesn't apply to everyone. A few exceptions is fine on occasion.
4. Every meeting has announcements out of habit instead of need. Be profession.

Make educated and informed decisions and don't hide behind over-applying or taking rules too literally.

Most of the Agile models provide a great starting structure for teams that are new to an agile process. That doesn't mean they can't be altered to suit your needs. If these announcements don't improve communication, don't do it. Seems simple, but ...