What are cycle time percentiles? But first… what is cycle time?

What are cycle times?

On the definition of workflow, you have at least one started point and one finished point. The cycle time is how long a work item takes to get from the start to the finish point.

Disclaimer: We round it up because if you start something and finish something on the same day, you do not say the cycle time is zero; you round it up to one.

So we can plot the cycle times on a cycle time scatter plot. Imagine on the horizontal axis you have elapsed time, and on the vertical axis you have cycle time (how long is the item taking). With this data, you can actually plot dots on the cycle time scatterplot — how long the cycle times were on given days in the calendar.

What does it show?

With the elapsed time on the horizontal, you can plot the cycle times on the vertical. This shows an interesting pattern — a trend of how long your cycle times are, how much variability there is etc.

What are cycle time percentiles?

How do you figure out what the percentiles are?

Say a child from primary school could lift a ruler up a page and lift the ruler up to where 50% of the dots are at or below that line. That’s the 50th percentile cycle time. In other words, 50% of your cycle times are at that cycle time or less.

You can lift the ruler up higher to 70th percentile to 80th percentile, 85th, 90th, 95th….

People don’t usually go to the 100th because that’s like saying what happened in the past will happen in the future, and with complexity, we’ve got unknown unknowns.

Why are cycle times relevant? Well, if a team or Kanban system members are getting together and they’re trying to figure out their service level expectation (SLE) (the aspiration for how long a workitem might take from start to finish, as long as the item has been right-sized, eg it is not the size of an elephant). How long might those items take?

If you look at the data on your cycle time scatter plot, the SLE (service level expectation) has:

• a percentage probability; and
• a number of days or less.

So you could say, the 85th percentile is 12 days or less, the 50th percentile is 7 days or less, and so on. It is essentially a forecast for an unstarted item.

When you have an unstarted item, and you pick that item, once you start it, you can use that as a guide for your expectations with your stakeholders. It’s not a guarantee; it’s just an expectation based on history, all things being equal and the same similar basket of work and so on.

You can set expectations with your customers and end users. But this begs the question…

Which percentile should you be using?

It depends really on your situation, on your context.

50th percentile

It is not that useful. It’s kind of like saying heads or tails. In my opinion, it’s not a very good way to manage your career.

70th-95th percentile

Most people would use the 70th percentile, maybe the 80th, 85th, 90th, 95th depending on the implications.

If we don’t deliver on time, if there was some legal requirement, you might go for 95th percentile, but be careful with 90th and 95th percentile because the difference in time between 85th and 95th can often be a lot.

It is good to observe how much of a difference there is between the 50th percentile, the 70th, the 80th, the 85th, the 90th, and the 95th.

Something I do if I notice that, for example, there’s a big difference between the 85th percentile and the 95th percentile, and I don’t want the customer to be misled, like, for example, if the 85th percentile is 12 days or less, but the 95th is 19 days or less.

That’s quite important information for the customer to know. I wouldn’t want them to think that the 95th percentile is less than that. So what I do with teams on the Kanban boards is I ask them to show two service level expectations. You only need to have one on the definition of workflow.

But… I like to show two to see the difference between the 85th and the 95th.

Multiple Service Level Expectations (SLEs)?

I have even had service-level expectations for different types of work item types. They’re optional in the Kanban Guide, but in the definitions file, you’ll notice that you can have work item types. I find work item types to be very useful in non-software.

There can be differences in how long the work takes because some of the work can be very different. That said, we all understand that how long something takes is very little to do with the estimated effort, but there are different types of work and sometimes it is relevant, especially with non-software; I find it’s very relevant.

Concluding Remarks

So with cycle time scatter plots, I tend to color the cycle time scatter plots for the different types of work item type so I can produce a service level expectation for, say, the 85th percentile for packaging and the 85th percentile for communications, the 85th percentile for acquisitions, 85th percentile for activations and so on.

They might be very different, and in different work items on your Kanban board, you can show those different SLEs on the board, but you only need to have one in Kanban.

So how worried do you need to be about the different percentiles?

I don’t think so much, but you need to be cognizant of how likely it is that your customers and end users might be misled by your SLE if there is a big discrepancy between the different SLEs.

Sometimes it’s sensible to have more than one SLE, which is what I do in practice.

Thank you.