One of the most common questions in software engineering management is: What is our team’s average cycle time?. It seems like a simple, useful question. It is not. It is the wrong question, and the answer it provides is often a dangerous lie.
A single number, like an average, hides the most important information about your development process. To truly understand your team’s performance and predictability, you must stop thinking in single numbers and start thinking in distributions.
A single task, once completed, has its own, unchangeable cycle time. But a team, over a period of time, does not have one cycle time. It has many. It has a distribution of cycle times. The average of this distribution is not necessarily the most important value.
Imagine your team completed 23 tasks in the last few months. The cycle times in days were: [1, 1, 2, 2, 3, 3, 3, 4, 4, 5, 5, 6, 7, 10, 25, 28, 30, 32, 35, 40].
The average (mean) is about 12 days. The median (the 50th percentile) is 5 days. Which number is “the” cycle time? Neither. Both are just single points in a much more interesting story.
A much better way to understand this data is to look at its percentiles. This allows us to create practical estimation buckets for future work.
-
25th Percentile (S): 3 days. 25{2d86e206823e03865fa8be0e21e9a6ee7441ee8bfd1fad108302568e2129cc3f} of our tasks are finished in 3 days or less.
-
50th Percentile (M – Median): 5 days. Half of our tasks are finished in 5 days or less.
-
75th Percentile (L): 25 days. 75{2d86e206823e03865fa8be0e21e9a6ee7441ee8bfd1fad108302568e2129cc3f} of our tasks are finished in 25 days or less BUT it also means that 25{2d86e206823e03865fa8be0e21e9a6ee7441ee8bfd1fad108302568e2129cc3f} of tasks are finished between 6 and 25 days.
-
100th Percentile (XL): 40 days. All our tasks are finished within 40 days BUT it also means that 25{2d86e206823e03865fa8be0e21e9a6ee7441ee8bfd1fad108302568e2129cc3f} of tasks are finished between 28 and 40 days.
Notice the jump. The difference between an S-sized task and an M-sized task is small (2 days). But the jump from M to L is huge (20 days!). This is where the real story is.
The most important and actionable information in any cycle time distribution is in its long tail: the tasks that take significantly longer than the median. In our example, it is everything from the 75th percentile upwards.
These outliers are not just “unlucky tasks.” They are signals of systemic problems: hidden dependencies, unclear requirements, external blockers, or long waits for code reviews. Analyzing these few, slow tasks will give you more insight into improving your process than analyzing the many, fast tasks.
This leads to a few practical conclusions:
-
Look Above the Median: You must pay more attention to the cycle times *above* the median to understand the real risks and sources of delay in your system.
-
Communicate the Spread: Giving a single “average cycle time” to upper management is a form of professional malpractice. You must inform them about the spread. Show them the percentiles. Show them the standard deviation. And, most importantly, EDUCATE them on what these numbers mean.
-
Track the Trend: These numbers are dynamic. Your “M” from today might mean something different in three months. You must monitor the trend of your percentiles over time.
And the most important conclusion is this: If the tasks above your median deviate significantly from it, you must perform a root cause analysis. This is why you can never look at just one metric. You need a system of metrics that allows you to find the why behind the what after you have stated a fact.
As I have written in previous posts, an average is not enough. We must think in distributions and probabilities if we want a realistic view of reality. A single number tells you a fact. A distribution tells you a story. And a system of metrics helps you find the truth.
If you’re facing challenges with metrics, forecasting, or measuring the true impact of AI in your engineering organization, let’s have a no-commitment conversation.
