Story-Based Stand-Ups

Many agile teams have become accustomed to conducting stand-ups, but there are times when the basic stand-up may not be as effective and efficient as communicating progress and aiding team with work re-synchronization.

The basic Stand-Up typically follows this protocol:

  • The team recognizes the Stand-Up is about to start;
  • In a clock-wise fashion each team member, as well as the scrum master, answers the following questions:
  1. “What did I get done yesterday?”
  2. “What do I plan on accomplishing today?”
  3. “Do I have any impediments?”

This type of stand-up works fine, but for team members that are remote this can be challenging for a variety of reasons:

  • Team members often don’t speak up during the tele-conference call.
  • Team members tend to fail to indicate which stories they are working on.
  • The continuity of a story and its completion is broken up as we go around the team room during the Stand-Up.

If you are experiencing this problem, or want to experiment with something different, I have had some teams change to a story focus during their Stand-Ups.  Instead of having the organizing principle be the individual, the organizing principle shifts to the story.  As Larman and Vodde state in Scaling Lean & Agile Development, “this allows us to focus on the baton and not the runner”.

A Story-Based Stand-Up would proceed as follows:

  • The team recognizes the Stand-Up is about to start;
  • Based on story priority, with the most important story going first, each team member working on that story or planning to work on that story, answers the following questions:
  1. “For this story, what did I get done yesterday?”
  2. “For this story, what do I plan on getting done today?”
  3. “For this story, do I have impediments?”

Since it is story based, if a team member is working on more than one story he will address his progress when it comes time to discuss the other story.

Pro(s) of this approach: Shifts from individual to story.  Keeps the team focused on trying to finish a story.  Helps to not confuse effort with results, keeps the focus on delivering business value – the story.

Con(s) of this approach: Team members will speak multiple times, but only when their work lines up with story.  All work needs to be accounted for in stories (some would argue that’s a good thing.

Give it a try.  See if works for you.

Remember, don’t just “Do Agile,” “Be Agile!”

Leave a Reply

Your email address will not be published. Required fields are marked *