The Daily Standup (DSU) is a key ceremony in the Scrum Framework. When run effectively, it can ensure the Scrum team focuses on what’s important to meet the Sprint goal and commitment. When DSUs serve only as a status meeting, the value of the ceremony is lost.
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
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)
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)
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.
The basic point is right: standups are an anti-pattern and a dysfunction, perpetuated by Scrum.
The focus should, indeed - as the author says - on flow. But a standup is not a good process for that. For one thing, it is a recurring ceremony, instead of something that happens at any time whenever it is neeeded.
Most developers do not want to know what everyone is working on every day. What they want to know is,
1. How does everything fit together? - how will the various features that we are working on interact? What is the design approach for it all to integrate?
2. Has anything changed that affects me?
3. How are people going to be using our stuff, and what do they think of it so far?
None of that is what is talked about in a standup. Ergo, a standup is a waste of time.
Much better is to have an occasional design discussion - say every 3-5 days, as needed - where everyone discusses their approach.
And much better is to have the team lead stay in touch with what everyone is doing, so that if there is a problem, they hear about it right away, and can call the right people into a discussion: "How are we going to solve this?"
Why wait for the standup the next day?????
And yes, flow metrics, should be a major focus on the team lead: they should be a major topic of the retro; and during the discussion, the team(s) should discuss the flow activities and where the bottlenecks are, and where the sources of issues are, and how effective the feedback loops are, and if they are measuring the right things.
The standup is superfluous and distracting and a waste of everyone focus - which is tragic.
I have seen many standups that were indeed a waste of time and a high-functioning team does not wait for the standup to connect as necessary. Nevertheless, with my high-functioning globally distributed teams in which some team members only had a 1-2 hour overlap in working hours, the standup served as a critical opportunity to get the whole team together for 15-20 minutes to make connections or get clarifications that might not otherwise have occurred in as timely a manner.
A mindset shift may be in order here. As I stress in the article, the standup purpose is not about reporting status. It's an opportunity with all team members together based on a minimal daily time commitment to ensure the work is flowing properly. For co-located teams or teams for which there are several hours of working time overlap, it may indeed be pssible to forego the standup or to hold it less frequently than daily.
Like most anything where there may be complexity of one sort or another, it's best not to make blanket statements about what's valuable or not. It's situational, and I'd caution anyone from deciding a priori without knowing all the particulars of an Agile team's situation as to whether part of a process can be elimianted.
Really interesting article in how to become more flow-centric than person-centric. A question : when a task is in status "Dev Complete", please describe what work is being done in your team during this state. Code Review? Is it not better to name it "Code Review" instead of "Dev Complete" so it is clear what work is being done?
HI Rchard. I think the best status is "Dev Review" because in my experience it should be a combination of a code review and a quick smoke test on the functionality. Devs should strive to minimize the bugs that reach QA and they should spend a few minutes to check each other's solution so at least the happy path works as expected.