Daily Standup Tips - a Roundup
What are the best tips and techniques for running a good daily stand-up? Most Agile teams run Daily Standups – but according to Joakim Karlsson “most of the daily stand-ups out there are, quite frankly, pretty uninspiring things.” They turn into just another meeting that everyone is forced to attend, even worse a meeting they must attend daily vs. the traditional weekly.
Paul Wynia provides the example of a project where the project lead had no Agile training or experience and treated the Daily Standup as a daily status meeting:
She would have each person give a detailed description of each feature, bug, and interaction they had had in the previous day and all their work, including estimates, for the upcoming day. She would then get into a discussions with each person on almost every item. It got to the point where people would bring in notepads filled with work details and to capture the new assignments she would give out. With a team of only 5 people, she somehow managed to stretch the Daily Stand-up into 30-45 minutes a day of excruciating boredom.
Paul goes on to recommend that meeting be limited to 10 or at most 15 minutes. He then gives teams he’s coaching permission to walk away if the time limit is breached, sending the Scrum Master a signal about a problem with the way meeting is being run.
Joakim recommends:
- Focus on the goal – sharing information with fellow team members that will help the whole team get to done in the iteration
- Focus on the team – sharing information with everyone and not just a single manager.
- Discuss Elsewhere – don’t to solve problems in the standup instead schedule the time to solve later, when anyone who is interested may join.
- Come Prepared – to keep the standup short team members need to know what you’ve accomplished and what is left.
- Focus on Accomplishments – Joakim found that: “talking about accomplishments made provides a more positive attitude than just providing information on what parts of the system was worked on.”
- Make Commitments – instead of mechanical saying what they will work in the next 24 hrs, he gets people to commit to the rest of the team what they will achieve.
- Raise Impediments – did you have to touch 60 files to make small change?
Mike Cohn recommends that teams conduct their daily standups in front of their task boards, asking the speaker to point at the story they’re working on. In addition, Mike notes that as team size grows past 9 people that its easy for team members to lose track of what other people are working on.
Drew Stephens reports that his team uses “User Story Focused Daily Standups”. Like most Agile teams, Drew’s started with a fairly traditional standup but struggled as the team grew in size:
There was no longer enough work on a single story to occupy the entire team and thus we began to parallelize. We also noticed that many stories were staying active for longer periods of time and developing what we began calling “task tails” (where a story stagnates with the number of unvalidated tasks remaining consistently low for many days). We identified two primary reasons for the occurrence of task tails:
- Low code quality resulting in QA finding a trickling but steady stream of bugs
- Developers moving onto other stories when a story appeared to be close to done but was not actually done
As a result of these factors, our standups became confusing; a person often talked about a different story than the previous person and this ascertaining the current status of an individual story became difficult. Instead of focusing on what was needed to finish the active stories, the focus was on what each person was doing or about to do. A subtle distinction but one that was increasingly problematic.
Their solution – walk through the stories in progress, each person who worked on that story answers the three questions for that story. If the person has worked on more than one story then they speak to all of them (a potential smell). The Scrum Master keeps track of who has spoken and if by the end someone has spoken then there is probably an impediment.
Artem Marchenko, has several suggestions:
- No typing – if someone is taking notes on a laptop (or otherwise), they hold the power as they reinterpret what the team members said.
- If the team is reporting to the Scrum Master, then the SM should look away or in extreme cases turn their back.
In an interview with Henrik Larsson, Jason Yip (author of It's Not Just Standing Up: Patterns of Daily Stand-up Meetings) notes how is view of standups has changed:
I used to see it more about status. Then I shifted to see it more about commitment, mainly due to Mike Cohn’s writings. These days, I see it as more about problem-solving. My current preference is much more strongly toward a “walk-the-board” style of stand-up when a task / story board is available. I tend to emphasise much more the importance of focusing on completing work versus just people trying to be busy.
Having said that, there are still some aspects that haven’t changed over the years, such as the importance of keeping the ritual high-energy and being about sharing with the team versus reporting to
a leader.
What has worked for your team?
Previously on InfoQ: What makes a Good Standup?
Daily Walkabouts
by
C Curl
What I propose is the Daily Walkabout. Take timeout from your desktop and have a walkabout. Scrum teams are normally quite small, take a few minutes to catch up with everyone, but please don't queue up and make it a formal practice. Doesn't have to be around the desk, but you could tag along to the coffee machine, lunch, or the local pub after work, whatever. The key is not Communication - but to communicate (the verb).
Re: Daily Walkabouts
by
jason ray
Focus on accomplishment
by
J. B. Rainsberger
Focus on Accomplishments – Joakim found that: “talking about accomplishments made provides a more positive attitude than just providing information on what parts of the system was worked on.”
I ask these three questions:
1. What did you achieve yesterday?
2. What do you plan to achieve today?
3. What is stopping you from achieving everything in your plan?
I find that works wonders.
Re: Focus on accomplishment
by
Mark Levison
Cheers
Mark Levison
Agile Pain Relief Consulting
Via LinkedIn some more suggestions
by
Mark Levison
Start the meeting on-time, even if "key" people (who *isn't* key on your team?!) are not yet there. If they miss something important a few times, maybe they'll practice being on-time. And if they just have to skip it, there will be another one tomorrow.
My recent blog post on being late for stand-ups: powersoftwo.agileinstitute.com/2009/08/charging... - Rob Myers
Have a meeting moderator and a timekeeper. A stand up is just like any other meeting. I needs to be kept on time and its discussion framed. A moderator should prevent participants brainstorm and keep the purpose of the meetings present at all times (we should only talk about things done, things to do and problems encountered).
The time keeper will make sure no one consumes a more meeting slot than it needs to.
If anyone goes out of this trend, the moderator can ask the team if they need to schedule a full blown meeting to discuss a particular issue. I say that U should have a moderator and a timekeeper (not both in one person) for the simple reason that eventually the moderator will have to talk and the time keeper will serve as moderator at that time.
If you follow this advise please let me know how it worked - Higino Silva
Information sharing and problem-solving
by
Olivier Gourment
The reaction of a good (French) friend comes to mind when he first heard of the practice: "they have invented... coffee break!?" (it is very common for people working together to come to the coffee machine and chat. Work topics invariably pop up and problems get solved!)
My "formal" tips would be the following:
- Take the opportunity to share news that give some context to what the team is working on. Developers have to make many decisions in a day, and if they have the right information, they will make the right decisions.
- I agree with Jason Yip, these days I see the daily meeting as a way to get more problems solved, faster. This is really the goal of that meeting, and maybe that's what contributes to its success.
- Our product owner is pretty much a permanent fixture; I also think it helps tremendously in having the right information conveyed to the right people at the right time
Task Board on a Projector
by
Joe Parks
Joe Parks
HyperProductive, LLC
Re: Task Board on a Projector
by
Mark Levison
Cheers
Mark Levison
Agile Pain Relief Consulting
Re: Task Board on a Projector
by
Scott Dunn
Cheers,
Scott
Software Development and Human Capital - Leadership, Agile and Strengths
Re: Task Board on a Projector
by
Joe Parks
Joe Parks
HyperProductive, LLC
Re: Focus on accomplishment
by
Joakim Karlsson
What is the goal we as a team have for today?
How did we as a team do on our goal for yesterday?
What, if anything, hindered us as a team from reaching that goal?
That can help us team members see the common goals and impediments, and how our individual contributions affect those.
I wrote a small piece about that here.
Educational Content
Writing Usable APIs in Practice
Giovanni Asproni May 19, 2013




Hello stranger!
You need to Register an InfoQ account or Login to post comments. But there's so much more behind being registered.Get the most out of the InfoQ experience.
Tell us what you think