Daily Standup Purpose: It’s All About Flow, Not Status

The new 2020 version of The Scrum Guide has thankfully removed the "three questions" from the Daily Scrum/Daily Standup (DSU) section of the guide. Those who understand that The Scrum Guide is just that—a guide—and not a prescribed methodology have never felt bound to use the three questions anyway. The questions are:

• What did you accomplish yesterday?
• What do you commit to completing today?
• Are there any obstacles in your way that may prevent you from meeting your commitments?

While answering these three questions may lead managers to feel the team members are working hard, they do not provide actionable insight into how well the team is progressing against their sprint goal.

For many years in my role as an Agile coach, I've served as Scrum Master for 1–2 teams. This has kept me working day-to-day as a practitioner. In my current organization that I've been a part of for nearly five years, I've had the opportunity to partner with an executive director of development with whom I'm simpatico on how to run a DSU. Our focus has always been on the flow of work (user stories and bugs) from the In-Progress state (or In-Development state if you prefer) to the Accepted state during a Sprint.

Of course, it's not easy to focus on the workflow without a visual way to see the work. My teams always use a kanban board for this purpose. Using a kanban board (or Scrum board in Jira terminology) is critical to visualizing the teams' workflow within the Scrum Framework. However, using a visual board is not enough if it only includes work states and not queue states. Consider a kanban board that only consists of the following work states:

• Sprint Backlog
• In-Progress
• In-Test
• Done

With this minimal set of states, there is no insight into the wait times between work states. For example, suppose a user story moves from In-Development to In-Test. In that case, we have no insight into how much of the time spent in the In-Test state is spent testing versus waiting for a QA engineer to be available to test. We, therefore, have no insight into the flow efficiency (expressed as a percent) of the workflow process, defined as:

           [Work time / (Work time + Wait time)] x 100

Breaking it down further, In-Progress for most development teams consists of two separate sub-work states: In-Development and In-Review (by a peer). Thus, a complete set of states for a typical development team might include the following:

• Sprint Backlog/Ready to Pull (queue state)
• In-Development (work state)
• Ready for Review (queue state)
• In-Review (work state)
• Ready for Test (queue state)
• In-Test (work state)
• Ready for Acceptance (queue state)
• In Acceptance Review (work state)
• Accepted

With this or a similar set of states for a particular workflow, it would be possible to accurately measure the team's flow efficiency and identify bottlenecks based on the proportion of time work items spend in a specific queue state compared to the corresponding work state.

Note: It's also useful to set work-in-progress (WIP) limits for particular work states to discourage context switching between work items, though very mature teams may evolve beyond WIP limits based on the application of the Theory of Constraints.

In practice, most development teams will push back from using nine distinct states based on practical concerns over frequent state management of work items and fitting so many states on a kanban board without scrolling horizontally. My teams have compromised and use the following states for work items within a sprint:

• Defined (queue state)
• In-Progress (work state)
• Dev Complete (work state)
• Ready for Test (queue state)
• In-Test (work state)
• Completed (work state for product owner acceptance)
• Accepted

While this set of states often doesn't allow us to rigorously measure overall flow efficiency, it provides enough information for useful DSUs that are workflow and work item-centric instead of being team member-centric. With my globally distributed teams, I display the kanban board in our video call and "walk the board," which means moving from right to left, discussing every work item in the Completed to In-Progress states. We start from the right because our focus is getting work items to the Accepted state, and those closest to Acceptance have the best chance of getting accepted within the sprint.

This format, focused on flow, should include every team member's discussion because all work done by a Scrum team should be visible and represented on the board. Most leading Agile tools, such as Jira, Rally, and Azure DevOps, allow work items to include a visual indicator of how many days a work item has been in a particular state. Thus, the discussion of a work item stuck in a specific state for multiple days should include an open dialog on why it's not progressing, including any obstacles the team may be able to swarm to resolve.

My teams also change the owner of a work item based on its state—with the owner removed for queue states. As the facilitator, in real-time during a DSU if I see a work item in a work state without an owner, I'll ask the team to whom it should be assigned. Changing the owner based on the work state makes it clear while walking the board who should speak up on the work item's progress within a particular state.

Focusing on the flow of work instead of team member status can lead to much more efficient use of time and impactful discussion with improved transparency on the sprint's health during the DSUs. Seemingly small changes to the Scrum process, such as the focus on flow, can significantly improve value delivery.