3 . Daily Standup Purpose
It Is All About the Flow of Work
By Rich Stewart
TAKEAWAY
The Daily Standup (DSU) is a key ceremony in the Scrum Framework. When run effectively and focused on the flow of work, it can ensure the Scrum team focuses on what is important to meet: the Sprint goal. When the DSU serves 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 section (or Daily Standup, abbreviated as DSU, as some prefer).
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. The questions are, more or less, asked like this:
- 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 the 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.
Focusing on the Flow of Work
For many years in my role as an Agile coach, I have also served as Scrum Master for 1-2 teams. This has kept me working day-to-day as a practitioner.
In my prior organization that I was a part of for nearly five years, I had the opportunity to partner with an executive director of development with whom I was simpatico on how to run a DSU. Our focus was always 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 is 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 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 (as it is usually conceived) and not queue states.
Consider a Kanban board that only consists of the following 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 insights into the “flow efficiency” (expressed as a percent) of the workflow process, defined as:
FLOW EFFICIENCY
It examines the two basic components that make up your lead time: working time and waiting time.
Unless you are working on one thing at a time, and you never get interrupted, lead time has both of these components. Waiting time can be encountered for many reasons: dependencies, priority changes, too much work-in-progress, etc.
Stated in another way: work-in-progress is not always actually in progress. Flow efficiency tells us how often that is true.
Breaking it down further, In-Progress for most development teams consists of two separate sub-work states, i.e., 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 is 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, therefore, 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 does not allow us to measure overall flow efficiency rigorously, 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 –remember 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 is not progressing, including any obstacles the team may be able to “swarm” resolve.
SWARM
It is a pattern used by hyper-productive teams. It occurs when as many team members as possible work simultaneously on the same priority item. And they work on just that one item until it is done.
Have in mind that, in Scrum, every Sprint Backlog is comprised of items of differing importance. They all need to be completed before the end of the Sprint, but only one of these items can be the team’s top priority. When a team swarms they should do so on that top priority item.
It seems simple, but it can be more difficult than it sounds.
First Problem
Many organizations today have individuals, teams, and even the organization itself working on many projects that are all top priority.
This creates massive dysfunction and slows down the teams and organization. So, to reduce frustration, boost happiness and increase the team’s effectiveness they must focus on what is the most important story (or small piece of work).
Second Problem
Even though swarming may sound counterintuitive, many teams try to divide and conquer their backlogs by having individual members work on different items at the same time. The thinking is that it will lead to more being done since the work is happening at the same time. However, that is just not the case.
The most common cause of a team being late or not having everything done at the end of a Sprint is that everybody is working on their own thing. Everything is open and nothing is done.
This decreases the velocity of a team by creating a bottleneck at the end of the Sprint where everything has to be integrated and tested at once, when usually there is not enough time left to do so.
Third Problem
We, as a species, love distractions. We often have our focus shattered by emails, texts, phone calls, etc. Those distractions come at a cost, which is well described by the terms “context switching” and “multitasking.”
Every time you switch focus from one thing to the next, you lose a sizable percentage of your productivity. That is because you have to mentally reset and ramp-up, possibly use a different system, or move to a different place.
While “context switching” involves interruptions and disruptions that cause a mental shift from a task at hand to something totally unrelated, “multitasking” involves working on two or more work-related tasks at the same time.
When we think we are multitasking, most often we are not really doing two things at once, but instead, we are doing individual actions in rapid succession, or task-switching.
So-called multitasking divides our attention. It makes it harder for us to give our full attention to one thing.
Certainly, it might not be as apparent or impactful when we’re doing tasks that are simple and routine, like listening to music while walking, or folding laundry while watching TV. However, when the stakes are higher and the tasks are more complex, trying to multitask can negatively impact our lives –or even be dangerous.
Amazingly, most people keep multitasking and believe that they are doing just fine. And herein lies the myth of multitasking: scientifically only about 2.5% of the world’s population has the physical capacity to multitask.
Whatever reasons you have, you will lose productivity when you or your team buys into the fallacy of “multitasking.”
My teams also change the owner of a work item based on its state, with the owner removed for queue states. In real-time during a Daily Standup, as the facilitator, if I see a work item in a work state without an owner, I will 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.
Agile teams commonly deliver value (by deploying code) via a set of user stories commonly referred to as a feature (or epic). In principle, a Scrum team should only commit to user stories belonging to a single feature in a particular Sprint. However, there are a number of reasons why this may not always be the case.
Since the focus of the Scrum team (especially the Product Owner) is on the delivery of value, it is useful at times during a Daily Standup to filter the Kanban board by feature (as an attribute of a user story) to get a feature-centric view of the flow of this set of user stories.
Is the Daily Standup Really Necessary?
There are commentators who argue the Daily Standup is a waste of time for Scrum teams. I concur it is for teams that treat it as a status meeting. Additionally, for high-performing teams that always communicate information with each other in a timely manner, the Daily Standup can become unnecessary.
However, as an agile coach who has observed dozens of Scrum teams, it is truly the exception for teams to reach such a level of performance, or to maintain it as team composition changes over time.
Furthermore, when Scrum teams are globally distributed and only have limited time each day to connect, it is my experience that the Daily Standup is a critical connection point for the team to raise any issues or questions.
This is especially true when the product owner role is located several time zones distant from some or all of the developers. The short discussion around a user story or bug can lead to clarifications that otherwise might not happen for a couple of days, thus negatively impacting the flow of these work items.
Another reason to hold a Daily Standup is for developers to get timely feedback from the product owner on something that is “demoable,” even if it is in a development environment.
In fact, one of my Product Owners made the request early in my tenure as Scrum Master with the aforementioned teams to get these informal mid-sprint demos as soon as possible to avoid issues or minor redesign much later in the Sprint, discovered either during Product Owner acceptance or during the end-of-sprint demo.
What I eventually saw was a significant behavior shift by the developers. They realized the benefit of this early feedback and would request to do a quick demo during the Parking Lot, immediately after the Daily Standup.
TAKEAWAY
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 Daily Standups. Seemingly small changes to the Scrum process, such as the focus on flow, can significantly improve value delivery.
I am Rich Stewart and these are my agile-thoughts
2021 © Denver, Colorado, UNITED STATES by Rich Stewart
Rich Stewart is a consulting Agile Coach with ten years of experience working with Agile teams and leading agile transformations. He enjoys training, coaching, mentoring, and transforming how organizations get work done.
In his spare time, Rich and his wife Paula Stewart regularly collaborate and learn from each other while providing support to the global Agile community through mentoring, coaching, training and offering free games and tools on their website.
He enjoys the great outdoors of Colorado with Paula and their dog Sable.
If you learned something, share it!