The first thing that happens to a newly minted Scrum Master, regardless of their certification (SSM, CSM, PSM1), on their first day of work is the stark realization that the real world has the injection of unplanned work.
In a perfect world, the sprint is “protected”, and the injection of unplanned work is considered an anti-pattern.
The Scrum Guide states:
“During the Sprint:
- No changes are made that would endanger the Sprint Goal;
- Quality goals do not decrease; and,
- Scope may be clarified and re-negotiated between the Product Owner and Development Team as more is learned.”
But we don’t live in a perfect world ? and the injection of unplanned work is common.
A small list of some of the situations causing this unplanned work might include:
- “Real” expedited production support work (e.g. we’re losing money, or our brand is being damaged)
- “Perceived” expedited production support work (e.g. there’s a bug that is not causing a loss of money or brand damage being worked on)
- Decision by the HIPPO (Highest Paid Person’s Opinion) based on market forces or client complaints/needs that has nothing to do with the Sprint Goal
- Large code merges between teams or programs causing broken builds and havoc
- Pressures based on fixed date regulatory requirements that were put aside until the last moment and have now become an expedited request
- Work in support of a dependency discovered after sprint planning
Many times, when I ask Scrum Masters and teams how they handle unplanned work, I get a few responses that include:
- We never so "no" and suffer because of it
- If something must come into the sprint backlog mid-sprint, then something must come out
- We end up having to work overtime
- We end up having technical debt (e.g. code not elegantly written and will need to be refactored to scale)
- We end up not meeting the definition of done (e.g. automated tests are not written or don’t pass)
- We remove the work item(s) that was designated for the sprint for continuous improvement (e.g. the implementation of an agile engineering practice)
- We remove learning new things to work on the unplanned work (e.g. learning debt slowing us down for the future)
The one thing all of these have in common is that they are reactive in nature. Scrum requires “adaptive” planning to work properly and the injection of uncontrolled unplanned work has the team stopping and starting work a lot instead of just starting and finishing work.
Just about every Scrum Master has done the penny exercise and they understand that multi-tasking leads to not getting things done, yet here we are in the real world without the Scrum Framework giving us methods to constrain the impact of unplanned work.
Luckily, since scrum is a framework, we can bring in additional methods to make it more whole.
In this article, I will focus on the practices that we might implement inside of Scrum taken from the Kanban Method. These include:
- Swim lanes for Expedite, Fixed Date, and Standard
- Horizontal WIP limit of “1” for the Expedite swim lane
- Run Chart with the number of “expedited” items in the Sprint each day (added, WIP, done)
- Run Chart with the number of “expedited” items per Sprint (added, WIP, done)
- Cumulative Flow Diagram showing the injection of new “items” over time (with changes in lead times)
Swim Lanes
The Kanban Method recommends consideration of 4 different service level policies associated with the cost of delay: (1) expedite, (2) fixed date, (3) standard, and (4) intangible. Intangible means that it hasn’t been identified as being in one of the other three groups.
For me, the most interesting thing about swim lanes is that their use helps us make work visible. Without these, we may very well be treating all work the same based simply (and incorrectly) on the order in the backlog.
It is common to not see the truth that is right in front of our eyes because we haven’t made work visible. The Kanban Method’s swim lanes help us make work visible so that we can make decisions on how to proceed, yet this alone is not enough.
WIP Limits on Expedite Swim Lane
The next step is to place a horizontal WIP limit of “1” on the expedite swim lane. This means that only 1 item can be in the expedite swim lane at any one time. It also means that this item can overrule a vertical column’s WIP limit by 1. We want to have this horizontal WIP limit because an expedited item means that we are losing money, or our brand is being damaged, and this means that we must swarm on to that item to get it done. If we didn’t have a horizontal WIP limit of 1 on the expedite swim lane, then swarming would not occur and an item in that swim lane would not truly be treated as being “expedited”, multi-tasking would occur, and things wouldn’t get done.
The HIPPO
Invariably, when there is an injection of unplanned work by the HIPPO, the HIPPO knows not what impact they are having in getting the real outcomes that they want. For many years, a standard technique used by agile coaches, scrum masters, and product owners has been to ask the HIPPO what they are willing to take out if they want to inject this new unplanned work. While this seems like a reasonable way of handling the situation, its use causes a self-defeating result: we are going to not only switch to work on something else, but we are putting unfinished work on hold. This means stopping and starting instead of starting and finishing and can only be considered waste.
As many studies have shown that the Pareto Rule (aka the 80/20 rule) applies to software development, stopping and starting like this can result in 80% waste (or rather, wait time). So, while the HIPPO has caused a stop and start with the injection of unplanned work with the desire to respond to market forces or client complaints/needs, the actual outcome is a longer lead time for items flowing through the system. This becomes and even greater challenge when the “expedited” work is not really expedited work, but only “perceived” as expedited. Just as we must have a clear understanding of the definition of done, we must also have a clear understanding of what “expedited” means. All too often, this lack of understanding of the cost of delay incurs negative feedback loops that cause damage to what the HIPPO wants most…shorter lead times and predictability in the system.
So, we must first have a clear understanding of what “expedited” means, make it visible in the Expedited swim lane, and limit the WIP to 1 in this horizontal lane.
But even this is not enough as the HIPPO hasn’t been given data that shows the impact of their decision to inject unplanned work.
Kanban Metrics
As mentioned earlier, there are several metrics that we might consider helping us with showing the HIPPO the impact of their decisions to inject unplanned work mid-sprint:
- Run Chart with the number of “expedited” items in the Sprint each day (added, WIP, done)
- Run Chart with the number of “expedited” items per Sprint (added, WIP, done)
- Cumulative Flow Diagram showing the injection of new “items” over time (with changes in lead time)
If 80% of the work items that a team gets done are expedited items, there are a few questions you might want to ask:
- First, is there any way to figure out if these items are “real” expedited items or just “perceived” expedited items? If they are just perceived and not real, then WIP limits on the expedited swim lane should help considerably because people will stop and ask: “what is “real”?”, and then further discussions will allow placement of the “perceived” yet not “real” work items into the standard or fixed date swim lanes for subsequent sequencing of work.
- Second, if 80% of the items worked on in a sprint are “real” expedited items, then we must ask two questions: (1) Is there a way to not have such high amounts of “real” expedited items? and if not, (2) Then why are we using the Scrum Framework in the first place? Any desire for obtaining predictability through Scrum rests on protecting the sprint from the intrusion of high amounts of unplanned work mid-sprint. So, if your current context has high amounts of real expedited work, then perhaps, Scrum is not the way to get to agility and we need to switch to the Kanban Method.
Printing out run charts showing the number of “expedited” items per sprint each day (added, WIP, done) and trending data of the same per sprint over several sprints, and how the lead time changes per day and per sprint (all taken from the Cumulative Flow Diagram), will show how the injection of unplanned work affects the lead time.
From these standard reports (provided by many agile project management software tools), we can create a chart of Lead Time versus Number of Expedited Items (added, WIP, done) over 1-day periods or over multiple sprints.
And remember, if the amount of WIP is the Queen, the lead time is the King. The amount of WIP in the system is a leading indicator of flow while the lead time is a lagging indicator. Yet, as Little’s Law tells us, these two are invariably connected with each other.
Showing this trending information together to the HIPPO will give them information on how to make better decisions. We simply show the trending data and ask the HIPPO: “Do you want greater predictability and shorter lead times?”. If yes, then let’s try this different way.
