Daily Standup Patterns

Introductory Note: I’ve used variations on the patterns described in this post with teams I’ve worked with, and I’m sharing this so others can experiment with these patterns as well, and create their own variations.

Desired Outcomes

Before we talk about patterns, regardless of which one we might choose to adopt, there are several desired outcomes from a Daily Scrum, aka Daily Standup, such as:

• Share knowledge
• Ask for help/volunteer to help somebody else
• Identify dependencies/risks
• Agree on next steps for anything that’s slowing the team down

Patterns

Even though there can be significant differences in terms of how each team might approach their Daily Standup, certain patterns are commonly observed. Before we get into patterns in detail, here are a few general tips that tend to be helpful:

• The standup is for the Developers on the Scrum Team (or the XP team; or the Kanban team, or any other flavor of Agile team); if anybody else is present, if they wish to speak, they should wait for all teams members to finish (some teams have a “Parking Lot” at the end; see also “After Party,” below)
• It can be helpful to get into the habit of making sure the Kanban board is up-to-date before the standup begins (by doing so, anybody on the team can easily see at a glance where the work items (user stories) are in the workflow, and time can be spent on more important topics, like addressing risk and uncertainty)
• Some teams have a different person on the team act as facilitator on a rotating basis, where that person keeps the conversation moving, and also helps make sure there are no “deep dives” during the conversation (it does not ALWAYS have to be a Scrum Master facilitating).
• Teams often agree on a verbal or visual cue whenever a deep dive starts to occur, such that any person on the team can give the deep dive signal, at which time that conversation is deferred to a Parking Lot at the end of the standup.

Pattern I: Focusing on Flow

In the Kanban Guide for Scrum Teams, the authors’ suggestions on how to facilitate a Daily Scrum with a focus on flow are likely to be helpful to many teams, because those suggestions focus the conversation “… on where flow is lacking and on what actions the Developers can take to get it back.” Thus they suggest the following prompts for conversation:

- What work items are blocked and what can be done to get them unblocked?

- What work is flowing slower than expected? What is the Work Item Age of each item in progress? What work items have violated or are about to violate their Service Level Expectation (SLE) and what can the Scrum Team do to get that work completed?

- Are there any factors not represented on the board that may impact our ability to complete work today?

- Have we learned anything new that might change what the Scrum Team has planned to work on next?

- Have we broken our WIP limit? And what can we do to ensure we can complete the work in progress?

Note: In regard to Work Item Age, many Application Lifecycle Management (ALM) tools include Kanban boards, and to varying degrees, they can also help surface important data points, such as Cycle Time and Work Item Age.

For fans of simple visual techniques that can be done outside of ALM tools, take note of what Agile practitioner Jimmy Janlén refers to as “dotting,” an example of which is shown below, from his book Toolbox for the Agile Coach: Visualization Examples.

The idea behind dotting is quite simple: For each additional day that a work item sits in an in-progress workflow state, add a dot to it. The dots provide a simple visual indicator of Work Item Age. (And, for more granular data, to show how long a work item sits in particular workflow states, use color-coding of the dots, or a similar technique, to differentiate which workflow states the dots apply to.)

Pattern II: Surfacing Blockers and Hidden Work

In her book Making Work Visible, Dominica DeGrandis describes another flow-based perspective on the most useful things to be talking about during a standup, where team members focus on:

• What work is blocked? (notice how this places the emphasis on the work, rather than the person)
• What work is at risk of being blocked? (this helps surface conflicting priorities)
• Is there work being done that isn’t on the board? (this tends to evolve into questions about work that might be invisible to the team, or problems that surfaced during a recent deployment, for instance)

Pattern III: Let the Work Items Speak

Letting the work items speak is analogous to what many Agile practitioners refer to as “walking the wall.” Many teams find it helpful to shift the focus of conversation from person-by-person updates to talk about in-progress user stories, in priority order, where the the team member(s) working on a user story might talk talk about:

• what they’ve learned from working on the user story
• what help they might need to complete the user story
• whether anything is slowing down or stopping further progress on the user story

Note: It may seem like a subtle difference between having each person speak and having user stories speak, but it is an important one, because it shifts the focus away from what a single person is doing, and toward getting the most important work done.

Pattern IV: A Fun Variation on the Three Questions

In the book The Agile Samurai, Jonathan Rasmusson suggests framing what older versions of the Scrum Guide referred to as the “Three Questions” this way:

• What did I do to change the world yesterday?
• How am I going to crush it today?
• How am I going to blast through any obstacles unfortunate enough to be standing in my way?

Important note: A Daily Standup is NOT intended to be a status report. One of the potential challenges with using any variation on the Three Questions is that a standup can easily devolve into status reporting.

Pattern V: Daily Standup Routine

In his book Toolbox for the Agile Coach: Visualization Examples, Jimmy Janlén describes visual techniques for making Agile practices more effective and interactive, one of which is what he calls a “Daily Standup Routine,” where a team posts a series of steps it follows in a visible location, for every standup.

Below are a couple of different ways to have a “daily standup routine,” by doing things in a particular order, and injecting a bit of fun into the conversation:

Variation 1

1. Start the Call
2. Walk the Wall (take a quick look at where things are in the workflow)
3. Headlines (anything particularly urgent that needs to be discussed?
4. Updates (blockers or other information team members would like to mention)
5. High Five (just like it sounds, either physical or virtual … ; )
6. After Party (synonymous with a Parking Lot — a time to have a follow-up conversation, if necessary; in some cases, only a subset of team members are needed for this conversation).
7. Update board (if anything on the card wall/the virtual board moved during the conversation)

Variation 2

1. Initiate (start call)
2. Cards (see where cards are in the workflow)
3. Assemble (gather in a circle, if collocated)
4. Headlines (what’s urgent that we need to talk about?)
5. Focus (any particular cards or issues that we need to focus on today?)
6. Updates (blockers or other information team members would like to mention)
7. Closure (high five or simple verbal cue that the team agrees means the standup is over)
8. Parking Lot (for any deep dive topics that need to be revisited, possibly with less than the full team present)
9. Follow Up (reminder for the facilitator to follow up on any blockers or other issues raised that need to be looked into)

Pattern VI: Mashups

Some teams mix and match by adding one or more questions/topics that they routinely discuss during a standup, by including questions such as those below, along with others listed in other examples above:

• What code smell/missing test did I find yesterday?
• What improvement did I make to the code/to the test yesterday?
• What did I discover or learn?
• What can I do to help another team member?