Team Practices Group/Scrum Standup
 | This page is obsolete. It is being retained for archival purposes. It may document extensions or features that are obsolete and/or no longer supported. Do not rely on the information here being up-to-date. |
 | This page is currently a draft.
|
Purpose of this Document
[edit]This page documents the Team Practices Group (TPG)'s recommendations for how to execute an effective Scrum standup. This document is based on best practices in software development, guidance from the Agile Manifesto, and TPG members' experiences. It is intended to serve as a guideline for running an effective Scrum standup, particularly from the POV of a Scrum Master.
Purpose of Standup
[edit]Standups, typically timeboxed at 15 minutes, get all members of a team on the same page. It facilitates self-organization and coordination between standups (typically daily, but not always. The standup is an opportunity to show work and see others' work, in order to increase visibility and identify blockers to tasks. Ulitmately, standup is a core component of facilitating mutual ownership of a project, as well as excitement to work.
Standup Process Overview
[edit]An effective daily standup is focused on information sharing, not problem-solving. Therefore, it can be most effective to allow each person in the standup to speak before anyone asks questions or offers comments. Alternately, teams may allow clarification questions; in this case, teams (and Scrum Masters) should pause any ongoing conversation and ask team members to continue with the standup and hold detailed discussion until after. After everyone has spoken, the standup is over and the team may decide who should remain for further discussion.
What Standup is NOT for
[edit]Standup has one role in Scrum. Stand up is not the place for:
- Long drawn out technical deep dives.
- Also known as "parking lots," "sidebars," "dead kittens," or getting into "the weeds."
- Things that are working well/not working well in process or communication (this is what the Sprint Retrospective is for)
- Commentary longer than a couple of minutes per person (standup is only 15 minutes long),
- Monitoring of team members' work (the focus is what they're working on, not that they're working).
Pre-standup
[edit]The following should be prepared by the Scrum Master ahead of standup:
- Provide links to the sprint boards, ready and available to the team
- Ensure the physical meeting space is available (if not remote)
- Review sprint board and get a brief overview of the state of the sprint
- Are there a lot of tasks in certain columns?
- Has a task been stuck in a certain state since last standup?
- Take a scan over email and calendar and note who won't be attending
During standup
[edit]- Start on time
- Determine who goes first (team, person)
- Encourage team to "pass the mic" to one another
- This gives the team the sense of soliciting and listening to each other, vs providing a status report to a manager
- Support the team focus on what they did, what they're doing next and what's blocking (if anything)
- Encourage brevity and valuable commentary/clarity
- "I'm supporting QA." OK, how?
- Ask about any other business/actions that need to take place (meetings, dead kittens, etc.)
- Make sure that conversations pertain to things on the board.
- Ask for tickets to be created for unrelated or new large tasks
- Keep the tone light to indicate that this is an "easy" meeting
- Remind people where they are in the sprint (usually reserved for mid-way)
Post-standup
[edit]- Follow-up with people on action items that came out of standup if needed
- Schedule meetings for any dead kittens that appear
- Investigate remaining blockers
- Ensure that anyone who missed standup is informed
stuff to discuss later
[edit]- stories are comprehensible three months later with a hangover