Kanban — Classes of Service
How do you use the expedite swim lane?
“There needs to be best efforts to get this done ASAP”
Taking my son to school today was painful. We need to drive and park in the car park so that I can get his wheelchair out.
Cars were queuing out into the main road. People were everywhere, flitting around. Children were running between cars. A car was blocking cars, hence the queue. It was chaos. I was nervous about hitting someone. There was just too much going on.
I wish I was treated like a VIP. A modern Moses, that would part the hoards of people and cars
and allow me to reach the sanctity of the empty space at the back of the school car park.
Realising that I wasn’t sitting in traffic; I had become traffic; myself part of the problem.
Still yearning to the treated as an exception, I wanted a different class of service to everyone else on the school run that day.
Classes of Service
Classes of Service (CoS) are one of the more advanced features of Kanban. However, their implementation doesn’t need to be massively complicated to get value from this paradigm.
The idea is that different types of work are treated differently. Traditionally, there are four different classes:
- Expedite
- Fixed Date
- Standard
- Intangible
In our current team (see Shape of You), we haven’t gone full fat CoS, but we do have two expedite swim lanes. There’s one for our SRE portion of our board, and another for our Feature portion. These complement our standard class which we use as the default.
We do have fixed date and intangible classes, but they’re more implicit. The fixed date class feeds into our expedite classes and the intangible items just have a lower priority.
Myself, the product owner manages the Feature Expedite, and the SRE Lead manages the SRE Expedite. We both do it in different ways! Don’t worry, it’s okay :)
SRE Expedite CoS
The SRE works is prioritised by using a plugin called Foxly. Each Jira ticket is then given a number, the higher the more important. The tickets are ordered on the board in this descending priority order.
Our workflow is to take the top ticket next, so in theory then most important piece of work is the one that gets lucky.
The prioritisation works very well due to the volume of SRE work that there currently is.
Fixed date deliverables, departmental goals and immediate actions from incidents aren’t taken into consideration when it comes to Foxly. But these clearly fall under a different CoS.
To get this work into the expedite column, we can set a date on the ticket and it’ll pop up nicely.
The developers then when finishing a ticket still take from the top, but if there’s something in expedite then they should take that ticket over non-expedite ones.
Pros
- Easy to get a ticket into the expedite swim lane
- Doesn’t interfere with existing Foxly Prioritisation
- Less stress on the team
Cons
- Can have multiple tickets in our expedite column reducing perceived importance
- Fragments SRE / Makes the board look noisy
Feature Expedite CoS
When it comes to Feature work, I use the expedite swim lane in a different way. If we have a critical piece of work, then I update the priority to expedite.
To keep myself honest — so I don’t abuse the expedite column — I document the reason for expediting in the Jira ticket. There should also be no more than one expedite ticket on the board at once and a good break between expedite tickets if possible. For me, these tickets should be an exception to our usual way of working.
Here’s why. The expectation for the expedite column in Feature is quite different. They people on Feature need to drop what they’re doing straight away and jump on this ticket. All of them if needs be. There needs to be best efforts to get this done ASAP!
Pros
- Easy to get a ticket into the expedite swim lane
- Reduced frequency keeps the board tidy
- Extreme focus on these tickets
Cons
- Very disruptive for the team
- Can easily be abused if not treated carefully
Example
Issues
The main issue with both approaches is that we have two approaches. But these variances are highlighted on our daily stand ups when it comes to picking up the next task. There’s a small bit more of cognitive processing required, but it’s minor.
Also, I can’t remember any time where the two methods have caused us any issues. They work together in harmony.
To sum up, neither approach is wrong, each fit the needs of the work in progress. I’m sure other teams do this differently, are much more rigid; or formal.
What I will say to conclude is that if you’re:
Continually injecting in tickets to be expedited so that these form the basis of your work…
Or that:
EVERYTHING IS URGENT
Then you need to look at those things.
Like I need to make sure that I look out for the other children on the school run. There’s something intrinsically wrong if I keep ploughing through them on the playground.
Thank you for reading this article! Please leave a comment below if you have any questions or feedback.
If you enjoyed this article then please consider buying me a coffee:
Chris Sheldon is a Project Manager for DataArt Ltd. DataArt are a global software engineering firm that takes a uniquely human approach to solving problems.
In his career Chris Sheldon has been a Software Developer, Scrum Master, Development Manager and more. He’s decided that people are harder than process, so this is where his attention is now targeted!
Chris graduated in the UK from Reading University with a degree in Electronic Engineering and Cybernetics.
A bit of a Agile enthusiast, productivity nerd and Wantrepreneur Chris really needs to decide what he wants to do in life and focus.
You can connect with him on LinkedIn, Twitter, Facebook, or by visiting his website, ITsChrisSheldon