Stand-up Meetings and Visual Aids

 Note: This is the first post of our new ‘multi-chronicler’ format so we just heard how we should try to limit the length of our posts… oops.

For a 15 minute meeting with three simple questions, I’m amazed at how complex stand-up meetings can be. A while back I made it my goal to understand more about them and I read everything I could find on the web. The best article I found on the topic is It’s Not Just Standing Up: Patterns of Daily Stand-up Meetings by Jason Yip. This article, like many of the others that I read, suggests having the sprint backlog or a big visible chart available as a visual aid for the meeting.  However, I haven’t read anything that explains how to use those visual aids in a stand-up meeting. The purpose of this post is to start the discussion on the different ways visual aids can and should be used during a stand-up meeting. Even if you don’t read my whole extendo-blog, I encourage you to add your comments about how you use visual aids in your stand-up. What works for you and what doesn’t?

Importance of Visual Aids 

Visual aids add value to a meeting because they provide a focus and context for what is being discussed. For example, having the backlog visible might help a team member remember a task which he or she completed the previous day. Visual aids could also help reinforce team goals, such doing a better job of ganging up on stories.

As many others have pointed out, searching out important progress reports requires an activation energy that is too high for most busy people, especially those who would rather be looking at code. Big visible charts need to be displayed somewhere that is highly accessible for the team. I’ve yet to come across a team that displays burn downs above the urinals, but it’s only a matter of time. The location of stand-up is the one other place that you can be sure everyone will visit at least once a day. 

Finally, some people are more auditory and others are more visual. Highly visual members of your team may find it difficult to continually focus on what the speaker is saying and not focus on what they are seeing. A visual aid can give them something to look at that helps keep their focus on the speaker’s words, instead of what the speaker is wearing.

Stand-up Visual Aids 

Although visual aids can be an important part of stand-up meetings, they can also be used incorrectly and detract from the purpose of stand-up. When considering how to use a visual aid, you must carefully consider how its usage will help address the goals of the stand-up, which Yip summarized as:

• share commitment
• communicate daily status
• identify obstacles
• set direction and focus
• build a team

Let’s look at three different visual aids and how they are best used during stand-up: Iteration Burn Down, Cumulative Flow Diagram, and Task Board.  At VersionOne we are lucky enough to have a 42” monitor mounted on the wall we use for viewing this info.  

Iteration Burn Down

An up to date iteration burn down is an excellent way for a team to provide visibility into their progress. Unfortunately, many teams don’t make the chart visible or keep it up to date. Sometimes our customers tell me that their team members don’t like updating remaining hours on tasks. My recommendation is to make burn downs visible at stand-up and create the expectation that any updates required for an accurate burn down will be made before stand-up. I don’t think that burn downs need to be explicitly used every stand-up, but the burn down can provide a timely reality check for how the iteration is progressing. For example, when a team is considerably above the ideal burn down line and half way through the iteration, the burn down chart can help start a discussion about how much Rockstar needs to be ordered. 

Cumulative Flow Diagram

Cumulative flow diagrams are one of my favorite metrics because they quickly provide feedback on the amount of work in progress at specific times in the iteration. With them a team can get answers to insightful questions such as

•  How long does it take our first story to be completed?
•  Are we completing stories before moving on to the next one?
• Is the amount of estimate in our iterations staying the same?

Like burn downs, cumulative flow diagrams shouldn’t be referenced every day at stand-up, but they can be very useful tools at certain times. For example, if the team is trying to get better at completing stories before moving on to the next one, a big visible chart that clearly shows when the first story is completed provides an opportunity to incent that behavior.

Task Board / Backlog

A task board is useful during stand-up because it focuses the team on the prioritized backlog, provides a granular representation of progress, and shows ownership of tasks. If you are unfamiliar with task boards, Mike Cohn does an excellent job of explaining them in his book Agile Estimating and Planning.

Unlike the other charts that I described, a task board or some other representation of the backlog should be a more integral part of the stand-up meeting. The task board makes it easy to reference tasks and ensures that the team doesn’t forget to consider a task that it would make sense to complete in the following day’s work. I recommend using the task board in the following way:

• All updates from the previous day should be made before the meeting begins so time is not wasted.
•  Only update the task board during stand-up if you can do so without disrupting the rhythm of the meeting.
•  The same person should not be updating the task board every day because that will promote reporting to the leader.

If your team has become hypnotized watching the tasks move during stand-up, help them snap out of it with the following panacea: “The most important goal of stand-up is allowing the team to share commitment. How does moving tasks on a board meet this goal?”

Final Thoughts 

An environment that includes a few key visual aids can improve the effectiveness of stand-up, but only if those visual aids are up to date before the meeting. If they aren’t up to date, then the task of updating becomes an unwanted purpose of the meeting and may also promote reporting to the leader.

Comments

[Ron Jeffries]

In an article about visual aids, examples of the kind of visual aids you're talking about would be great to see. I urge you to update to include samples!

Thanks!

[Andy Powell]

Ron, good idea. I'll add some examples this week.

[obie]

I've had success using a projector in the daily scrum to chart tasks, time remaining, and burndown all at once. The team does the roundtable of what they worked on, and are working on today, and as they are talking, are asked how much time is left and the driver updates the task - that way you get a realtime view and you know everyone has entered their data - nothing kills a burndown chart faster than a process where the data that backs it is out of date. At the end of the meeting, the focus flips to the burndown. The key is to have a tool that seemlessly lets you modify tasks on the fly, very very quickly.

[Jack VanDenHeerik]

It would also be prudent to ensure that everyone present for the stand-up presentation is given a hand-out of the visual aids (slides). The benefit is that the context of the presentation is taken with them and can be refered to later.

[Peter P.]

Interesting points but adding this level of complexity, though relatively minimal, seems to make the stand-up far more complex than it is intended to be. Visuals are excellent tools but as soon as you introduce them you take the focus from the team to the screen and you add a host of other needs to support the meeting. I would suggest that this is best suited for a iteration review meeting that identifies weaknesses in team practices, such as updating status.

Moreover, the following line struck me as highly antithetical to Agile ideals: For example, when a team is considerably above the ideal burn down line and half way through the iteration, the burn down chart can help start a discussion about how much Rockstar needs to be ordered.

One of the great things about Agile approaches is the idea that it allows future planning with some degree of expected accuracy based on previous performance. If that performance is based on Rockstar-driven hours, you've blown your ability to estimate accurately and cannot trust that your previous results will be repeatable. You have also then set a precedence that quickly leads down the path to team burn-out. Now that the team is driven by deadlines, what was the point of prioritizing features at the beginning of the iteration?

Maybe I'm reading more into this line than is there but it indicates to me that you have over-looked a fundamental point of Agile development, and that clouds my view of the rest of your ideas.