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:
The stand-up must never be...
The stand-up must consist of answering the three questions:
The answers to these questions are brief:
Any discussion outside these questions is part of another, different meeting, perhaps for the "meeting after the meeting."
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...
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.
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.