Lead Time is the time between when a feature starts and when it’s deployed to production. It’s a standard performance metric for software development. It measures all the processes in the software development cycle, from requirements gathering to testing.
Lead Time is heavily affected by uncertainty. The more uncertainty, the longer the Lead Time.
To demonstrate the influence of uncertainty quantitatively, I created a simulation (well, Chat GPT did) of a process and ran it many times with different parameters.
I created a process that has four steps:
Step 1: Takes 3 days.
Step 2: Takes 4 days.
Step 3: Takes 5 days.
Step 4: Takes 3 days.
If we send a task to this process, it takes 15 days to complete (3 + 4 + 5 + 3 = 15). This is the Lead Time in this case.
Assuming that each step can work one task at a time, if I send a new task only one day after the first one it will stay waiting for the next task to finish that step.
I plotted what would happen to the lead time if there was a new task every 4, 5, and 6 days:
The Lead Time increases when there is a new task every four days because they get stuck before Step 3, which needs five days to complete.
Yet, the Lead Time stays constant at fifteen days when a new task is added every five or six days.
Let’s now add some variance to the steps:
Step 1: Takes 2, 3, or 4 days.
Step 2: Takes 3, 4, or 5 days.
Step 3: Takes 4, 5, or 6 days.
Step 4: Takes 2, 3, or 4 days.
I kept the average of each duration the same as before. Each duration has the same probability of being chosen. For example, a task might spend two days in Step 1, five days in Step 2, five days in Step 3, and two days in Step 5.
In the previous scenario, the Lead Time was always fifteen when a new task was added every five days. Is it still the case with the variance?
I ran the simulation 1000 times with those parameters and then plotted the average of Lead Times.
The sum of the averages is not the same as the Lead Time.
The reason is in Step 3. This step might take six days, which is higher than the frequency of new tasks (five days). Therefore, some tasks might get stuck in it waiting in Step 2.
Let’s add even more variance. We keep the average the same but add one day variance for each per step:
Step 1: Takes 1, 2, 3, 4, or 5 days.
Step 2: Takes 2, 3, 4, 5, or 6 days.
Step 3: Takes 3, 4, 5, 6, or 7 days.
Step 4: Takes 1, 2, 3, 4, or 5 days.
With more variance, the Lead Time average is even longer. That’s because Step 2 could also be a bottleneck when the task stays six days, and Step 3 is an even worse bottleneck with a duration of up to seven days.
Learnings from the simulation:
If we add variance, the average lead time is not the sum of duration averages.
The more variance, the higher the lead time.
The maximum duration of a step affects the Lead Time, not the average.
Based on the simulation, we can draw a main (theoretical) conclusion about managing lead time: “Manage Uncertainty.”
Variance in duration comes from the uncertainty of the task—the more uncertain a task, the higher the variance.
How to reduce uncertainty will be a whole article. But I’d like to give some examples to help understand what I mean by managing uncertainty:
Define non-functional requirements like performance, scalability, and reliability.
For example, specify that a list component needs to support hundreds of thousands of items or just tens.
Reduce the size of the tasks.
For example, create MVP of features.
Find and resolve open questions before starting the work.
Have a feature launch meeting with stakeholders and open communication.
Do post-mortems on tasks that exceed the expected duration.
This helps in learning how to improve tasks in the future.
Thanks to Elina and Sebastià for reviewing this article!
Let’s start the conversation. How do you reduce uncertainty in your feature development?
I’d appreciate it if you shared this article if you found it interesting!
Comments
Nothing yet. Say the first thing.
Sign in to join the conversation.