I play the ‘Get Kanban’ game a lot as part of my Kanban System Design Class and it never ceases to amaze me how reactive people are to expedite a ticket for whatever reason. This is also reflective of what I see in real life. The team are busy working away and then a ticket comes crashing in and everyone stops to jump on this, and no one batters an eyelid. Do we not know how bad expedites are for your system?
Let’s start the beginning…
What Is An Expedite?
It is highly likely that you call them something else, but I suspect they already exist in your system. You might know them as major Incidents or P1s. Whatever the name, they are tickets that have such importance that they have to be done immediately. Maybe your website can no longer take payment or your customers cannot access the reports they need.
The Kanban University describes it as ‘An archetype of a class of service that is applied to work items where the impact of delay is both high and immediate’. You can find this description and many more in their glossary.
They also use this image to describe that impact of delay.
It was changed not so long ago from ‘Cost of Delay’ to ‘Impact of Delay’. The reason being that not every expedite is a monetary thing. Either way, it describes the impact of not fixing this thing is costly and now.
Our First Mistake – Not Having a Explicit Policy
Just because an expedite has come in, it doesn’t mean we have to do it! Do we ever consider the impact of the expedite vs the cost of delaying other work? No, we don’t! Any expedite that comes in, someone says ‘Jump’ and we all say ‘How high?
A good practice would be to have an explicit policy that describes the conditions in which it would be true that we complete this work. E.G
- The loss of systems or functionality resulting in significant financial loss or usability
- The problem impacts the companies reputation
This would be best aligned across the organisation and so everyone has that same understanding.
We would also want to set a policy about how many of these can we take in at any time. Ideally just 1!
But the point is, we need to have something to validate this urgency against. We also need to consider the impact of delaying work that is already in flight. plus.. we must have the autonomy to say ‘Not yet’.
Our Second Mistake – Not Knowing How Many Impact You
Is an expedite something that happens once every 6 months or do you get 10 a week?
In my last blog I talked about understanding the demand for work item types. We also want to look at the frequency you get them. This information will determine our response.
Another factor you can look at is the impact of having 10 a week on your lead time. The punchline is that everything takes longer…. also if you have 10 a week, are they really an expedite?
This image shows expedites across an organisation. So you can do at team and organisational level. This image is taken from Power BI.
Our Third Mistake – Not Knowing The Cause Of The Expedite
If we have established that we are a team that gets expedites frequently, we need to do some analysis. What is causing these issues and how can we stop them from happening again in the future. Sounds like a great opportunity for a retrospective. The causes could be either inside or outside of our own system. Either way it’s our problem and we might have to collaborate with other teams to solve.
Patterns To Manage Expedites
If you get expedites very infrequently you can probably set some policies and this will be enough. Validate it is a true expedite and accept that is going to extend the lead time on other pieces of work you are doing. This can be managed easily between the team and product.
But…. If you get many and we cannot reduce that number through process improvement, we have to have a strategy to manage.
- Understand that I get X expedites per week and the 85% lead time for each of those is X days.
- Schedule a regular expedite retrospective to understand root cause analysis and mitigation
- Consider adding an expedite swim lane or use colours to make it very visible (Shown below)
- Allow capacity allocation for expedites (shown below). Out of a WIP of 9 I am accounting for 2 expedites and 7 outcomes.
If I apply a capacity allocation for expedites it means when they come in, I do not have to stop other work. Therefore, not increasing other tickets lead times or impacting the teams roadmap commitment.
If no expedites are in the system, this does not mean that this time is wasted. I would pair with other people to increase the team skills and share knowledge, thus increasing staff liquidity. Then when the expedite comes in, you leave your pair, and no harm is done.
Knowing the team’s true capacity to work on outcomes is key for planning. So in this instance I can say the team does x tickets per week and can plan to that amount. But in reality if we are thinking about wider work item types you have to allow time for process improvement, unplanned work and walk up questions. So, you can see how work item types and knowing your demand and capacity is fundamental to managing your planning, flow of work, lead times and delivery rate.
Remember, whilst we now have a strategy to manage we have to keep challenging if these expedites need to be done, but also why they are happening in the first place.
What other strategies or advice do you have for managing expedites?