I’m passionate about understanding what makes software engineering teams great, and applying and sharing that understanding however I can. And of the many different ways I’ve seen software built over the years, I’m convinced that Agile and Scrum – if they are applied well – combine to form a highly successful approach to building software. To that end, I have several posts about different aspects of Agile and Scrum, based on my own experience over the years. Here’s one of them.
Scrum.org says, “The purpose of the Daily Scrum is to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary, adjusting the upcoming planned work.” In my experience, this is the method that has worked most effectively:
- Do NOT simply go around the room and give status updates. This meeting has a purpose, and that purpose is not served by “What did you do yesterday?” and “What are you doing today?” To rephrase scrum.org, the purpose is answering the question, “Do we need to change our sprint?” That is the question that matters.
All effective meetings are of four types: Learn, Decide, Do, and Bond. The Daily Stand-Up, as with most Sprint meetings, is a Decide meeting. Its purpose is to make a decision, and its content should contribute directly to that decision. The single best change to your Daily Stand-Up that you can make is to get away from this round-robin format.
We’ve all seen this format. It’s pervasive to the point that it doesn’t even hit our radar anymore. We simply take it for granted that this is how daily stand-ups are supposed to operate. But many of us recognize, instinctively, that there’s something wrong with it. When your instinct is telling you there’s something not quite right, listen to it. Figure out what it’s trying to tell you and make a change.
- Limit the meeting (ideally to 15 minutes). This is a daily meeting of the entire scrum team, and has the potential to consume a considerable amount of time over the course of a sprint. This limit can seem artificial if the round-robin anti-pattern is taking place, as time is often taken by those at the head of the line at the expense of those at the tail of it. But once the format is fixed, the time limit is no longer a problem.
Let’s assume a scrum team of six people is meeting daily for 15 minutes for a two-week sprint cycle. Let’s also assume that, for whatever reason, the stand-up is only occurring for eight of the ten days of the sprint, and that each participant requires zero time for context-switching before and after the stand-up (an admittedly false assumption). That is still 12 work hours spent by the team, cumulatively, on the daily stand-up. Twelve hours every sprint. And that’s the ideal. Reality is often far, far more than that.
In one situation, my team was meeting for 45 minutes to an hour every day. It was a drain in many ways, and I attempted at one point to fix it. What I learned the hard way (after half the team reacted negatively) was that the daily stand-up for my geographically diverse team actually served two purposes – Decide and Bond. This was the team’s opportunity to socialize, and I took that away. A better move would have been to separate the two, keeping the daily stand-up efficient while also providing the team with other ways to bond, but external factors meant that did not come to pass before I had moved on.
- Address the sprint goals in priority order. For each, ask this question: “Are we still on track to accomplish this goal by the end of the sprint?” If yes, then move on to the next goal (or user story). If no, then decide, then and there, how you will adjust. Do you move it out of the sprint? Do you move a lower priority item out of the sprint? Do you reduce the scope of this item? There are many actions that can be taken, and the only wrong one is to do nothing.
This is what makes the 15-minute time cap work. If you’re starting with the highest priority issue, then your 15 minutes is well-spent. If you get through all of the items, then that’s great! If not, then you still ensure that you’re covering the most important goals while keeping to the schedule.
This depends, of course, on having good prioritization. Many teams fail that step, and then – because they don’t have their work prioritized – they shrug off conducting their daily stand-ups this way. One typical excuse is that all of the individual contributors are “doing their own thing” anyway. If that’s the case, then re-evaluate how you’ve formed your scrum team. If you’re not working together toward common team goals, then you’re not really a team. And as part of that evaluation, I would even consider the possibility that perhaps the scrum format isn’t right for you.
And that’s what it takes for effective Daily Stand-Ups. Remember, above all, that it’s a Decide meeting. Make the appropriate decisions and then get on with your day.