Toward Scrum, part 4: The Stand-up

Russell Bateman
April 2017

The Scrum stand-up's purpose is to reassure every member of the team that the work being is the object of the sprint and that it is progressing. Yet, the Scrum stand-up is just about the most abused and mysterious of all trappings of the Scrum way. Here's why:

What the stand-up is not!

The stand-up must never be...

...a status or recording meeting,
...for micromanagement,
...only for the Scrummaster,
...a planning meeting,
...or a technical discussion or exposé!

The stand-up must consist of answering the three questions:

  1. What did I do yesterday?
  2. What am I doing today?
  3. What impediments, risks or obstacles are keeping me from working on my stories or tasks?

The answers to these questions are brief:

  1. I worked yesterday on the ________ task of the ____________ story.
  2. I am working today on the __________ task of the ___________ story.
  3. I'm having difficulty completing the ___________ task of the __________ story because I'm not greatly experienced in using Apache's HTTP client library. (OR) I think I may be falling behind schedule because IT haven't restored my connection to our test server. (ETC.)

Any discussion outside these questions is part of another, different meeting, perhaps for the "meeting after the meeting."

Dangerous stand-up antipatterns

Here are some antipatterns that characterize stand-ups going wrong. These tend to creep in as people lose sight of the purpose of the Agile process, Scrum and, in particular, the Scrum stand-up.

The stand-up is...

...becoming like holding a status meeting,
...dissolving into a problem-solving meeting,
...being hijacked for new requirements, refining stories or doing sprint planning,
...quiet when a team member calls for help (in question 3),
...abused by a team member taking excessive time,
...abused by members talking while another has "the speaker's token,"
...a forum for assigning tasks,
...a forum for managers to attend to get status,
...thought of as a factory siren starting the next shift,
...started late,
...seeing members showing up late,
...burdened by a large number of attendees,
...violated by talkative chickens.

Ideally, the stand-up should be held near a board or device that displays the artifacts of the team's sprint including stories and tasks so that the team members have easy reference as they answer the three questions.

The stand-up is for the team by the team. An Agile team is self-organized. Stand-up must not be the time for team members to report progress to a manager. Each team member should have an idea of all the work being accomplished by the team and understand how the stories and their tasks contribute to reaching the goal. If the breadth or scope of the work undertaken defies this, then it's not a team, but two or more teams.

When a team member expresses his or her answer to question 3, it's proper for another member to say, "I can help with that." It's not proper and it's a waste of time to lapse into technical discussions or expressing solutions whether one-on-one or in the general team forum.

To say that the stand-up is not a status meeting is not to say that what's voiced during stand-up should be construed as avoiding revealing status. Naturally, the answer to question 1 is implicitly status especially when voicing that something's been completed rather than merely in progress.

Suggestion

Instead of spending time in your daily talking about status updates that could easily be a Slack message, consider talking about priorities instead. Give developers a chance to say what their number one priority is and if anything is pulling them away from working on it.