Archives: August 14, 2023

Expedites Are Bad For Your System!

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.

I would:

  • 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?


Establishing Work Item Types

Understanding your demand and capability is a key part of Kanban, we can then use work-in-progress limits (WIP) to control the flow of work. But first, we truly have to understand the type of work our system is doing. Not all work is created equal! Not everything is a story, let alone the same size.

So we understand the different types of work the service does to enable us to analyse what type of work is getting done, how much is getting done, and how long that takes us. Service teams have many different priorities and it is important to keep the balance of all the different types.

So first we have to establish the type of work you do. The good news is you already have this information in your head or your online tool.

Once we have identified your work items, we want to align the meaning of these terms:

Work Item TypeDefinition
EpicBig User Story
StoryShort, simple description of a feature told from the perspective of the person who desires the new capability, usually a user or customer of the system (*taken from Mike Cohns website)
Escaped IssueA problem that has been identified in the live environment or with a customer
BugA problem that has been identified as the service team goes about their work
Technical DebtLess-than-optimal approach to speed up a piece of functionality or a project, which then later needs to be reworked.
SpikeA timeboxed investigation
SupportSupport from the wider business
ExpediteEmergency tickets that must be completed ASAP
Unplanned WorkWork that should have been planned, but slipped through the net
Examples only – You need to define these for yourselves

There might be more and that is fine. In some organisations I have worked at, we have aligned these across all service teams and not just one in isolation. This gives the benefit of everyone using the same terminology and you can see interesting trends across the data.

Most online tools will allow you to add your own work item types and so I would do an exercise to align the queue and the work that is in flight to these new definitions.

We need to allow work to be completed before we can start analysing the results. You need very little in reality, somewhere between 7-15 tickets to be completed.

Delivery Rate

Screenshots taken from Power BI, and other tools are available!

So the first thing we can look at is the delivery rate of work. Simply this means, how much of this work item type are we getting done. I would typically have a chart for each different type. From this you can now take action e.g do we have a quality issue or is there too much-unplanned work coming our way. If we can reduce the unplanned and spend less time on bugs, then the work you do on stories will increase.

Now we have this data, we can start being smart in terms of planning. If we have an 85% capacity of the service team for work, we can now shape the demand allocation and say 10% on tech debt, 10% on unplanned and so 65% available for stories. No team works on 100% stories and so why are we often naive and plan to do this? Don’t like the numbers you are spending not on stories, then what can we do to improve and shift the balance?

Things like unplanned work and expedites have a negative effect on the system as it distracts us. So maybe we need to introduce a WIP limit for expedites and an explicit policy to define what it means to be an expedite. If you are a team that gets hit by a lot of expedites, maybe you are a service support team, then at least we can understand the levels and plan accordingly.

The great thing about having data like this is that we can see the changes over time and the impacts of the process improvements you put in place.

Over time you might start to notice patterns in the demand. Maybe you get lots of requests at a certain point of the year. Knowing this means we can be prepared and ready.

How Long Work Takes

We can also start to build up a picture of how long each of these work items takes to get completed, the stability of that, and the trend. The chart below is from a service support team.

So I can see stories are being delivered with 85% confidence in 14 days or less. This has been reduced over the last three months because the team is taking action to break down work, better-manage dependencies, and limit their work in progress to really focus on getting work done.

This particular team can use these numbers to set service-level expectations (SLE) with their customers. Note, we would do this differently if you are working on a large outcome/project.

In this particular client, I have also noticed we effectively have small, medium, and large stories. The difference between small and large can be vast and so can impact the figures. So we now have a concept of an SLE for S, M, and L story work types.

It’s fair to say if you have Kanban systems to manage your portfolio boards, projects, features, and epics. We can also get the same information, just at a higher level.

Conclusion

By breaking into work items types we can start to use the data to understand and make decisions. We also take the feeling we are ‘not getting much done’ to something a bit more evidence-based. Naturally, the data is only as good as the input and so we have to improve that. But over time you will have nailed the process part and can really start to use your data to make decisions.

So maybe today is the day that you start thinking about your work item types?