Many managers and teams talk about “average” durations for work. On average, how long does it take a team to finish a certain kind of work? However, average doesn't quite explain why our work takes different durations. Instead of average, consider the word, “typical.”

I've written about cycle time before. (It's the time from when you start a specific task to when you finish it. (Totally finish it.) I had a terrific time discussing cycle time with Daniel Vacanti and Prateek Singh on a recent DrunkAgile video: A conversation with Johanna Rothman.

One of the concepts we discussed (about 36 minutes into the video), was the difference between typical and average. Here's an example. When I want to drive to the airport, I *typically* need about 30 minutes.

I have made it to the airport in as little as 20 minutes, but that doesn't happen very often. And I have spent as long as 90 minutes inching my way to the airport, wondering if I will get there in time for my flight.

If I average my drive-to-the-airport times, the average time might be fifty minutes. That's much larger than my typical duration of 30 minutes.

Why is the average time so much larger than typical?

Because the outliers drag the average one way or the other. During the pandemic, if I had driven to the airport, I bet I could have made my average drive much shorter. Not that much traffic. However, I didn't need to go to the airport, so driving during the pandemic isn't a useful data point to use for the average.

People want the average duration because they want to manage risk. But “average” hides the risk. “Typical” might better expose the risk.

## “Typical” Durations Expose Risk

Can we find a “typical” duration? I wrote about that in Low Tech Way to Visualize Your Percentile Confidence for Forecasts. (Note: a histogram is useful for a sprint or two. If you want more understanding, make it a time series plot, not a histogram.)

We can find our team's typical duration—even when the work is different in size.

When we focus on duration (which is what managers want to know), and we realize that work is longer than our typical or desired duration, we can ask the question, “What can we do to finish this faster?” (Not worse, just faster.)

The team has options:

- Depending on the relative rank of the item, other people might stop their work and collaborate (pair/mob) on the larger work in progress.
- If the work is large and ranked lower than everything else, maybe stop the larger work and finish all the other work. Then mob on this larger piece.
- Consider a short kaizen event to understand why the work is large.

However, the team knows *now *that they can act. The duration doesn't get even longer before the team acts.

## What About the Data?

Here's the data for the team with the cycle time histogram at the top of this post: The team tracked 20 items. The *typical* duration is the same as the 50% confidence: 5 days duration.

Now, assuming I used my spreadsheet properly:

- The Average time to complete an item is 8.1 days, which I will convert to 8. (Notice that there are 0 items that complete in 8 days.)
- The Median is 8 days. Again, 0 items complete in 8 days.
- The Typical cycle time is 5 days.

This team managed to complete 15 of their 20 items in 6 days or fewer. They have some outliers, but you can see that the cycle time has a significant cluster around 1-6 days.

However, I often work with teams that have more variation in their cycle times.

This team also tracked 20 items. This histogram might look better to you. Their longest item took just 14 days, not 15. And their 50% confidence is at 5 days; 80% confidence is at 10 days, and 90% confidence is at 12 days.

Here's their data:

- The Average time to complete is 9 days. (No item actually completes in 9 days.)
- The Median is 9 days. (No item actually completes in 9 days.)
- Their Typical cycle time is 5 days. (That's the 50% confidence number)

If you looked at the average or median, you would be surprised that the team finished “early.”

Average and median measures can fool us.

## Manage Schedule Risk with Typical Durations

Instead of average or median durations, we can manage schedule risk with typical measures—cycle time. When we have typical data, we can address schedule risk now. If the team realizes a specific item is past their typical time, they can choose from several options to address that problem as soon as they realize it.

Instead of averages when it comes to schedule, see if you can use typical durations. Then, see if you can manage your risks better. Let me know what you do.

Hi Johanna, I love your books and articles. I agree completely with your advice in this post but I don’t quite understand the math.

Isn’t “typical” and “median” equivalent? If I have 2 stories with a cycle time of 1 day, 3 at 2 days, 1 at 14 days, and 1 at 20 days, the median cycle time is 2 days, right? (1,1,2,2,2,14,20)

I assume I’m missing something since my calculation of average doesn’t match yours, either. My calculation of your second example gives me an average of 6.3 instead of 9:

(1+1+1+2+2+2+4+4+5+5+6+6+8+8+10+10+12+12+13+14) / 20

How should I calculate these?

Hi Darryl, okay, I do need to admit one thing: I am not very good at arithmetic. I am really good with symbols. I might have screwed up and I hope I didn’t. Sigh. That said, here’s what I did (which might be wrong!):

– I assumed that the typical duration is the 50% cycle time duration.

– Median is the middle. In your example, the middle is 2 days. And, you are correct that the typical (50%) duration would also be 2 days. However, given the wide range and the few number of stories, I would not use that to forecast.

For the data I presented, I created a spreadsheet. (Because arithmetic.) And, because I knew I would screw up with a long list, I multiplied the number of items for each time by the time. I think that’s correct. Then, to find the average, I took all the sums and divided them by 20 (the number of items) to find the average and the median. Nuts, maybe that’s where I went wrong.

I just did this: for the first data, I added all the sums together and then divided by 20 and got 6.1. That’s still higher than the 50% confidence cycle time, which I’m calling the typical time.

For the second team, I also got 6.3. I don’t understand why I calculate one way and get one answer and another way and get a different answer. I must be wrong.

However. Let me try to redeem myself 🙂

If we use the 50% cycle time as our “typical” time, and we stop with my wrong math, we still get the point I was trying to make. Except without the wrong math.

Thank you for letting me know. And thank you for reading and (mostly!) appreciating my books and articles. I will stop trying to do public arithmetic. Sigh.