How to be predictable without estimation

Estimating knowledge work (e.g. software development) has always been a big challenge. Developers and team leaders try to help managers and clients to predict budgets, prioritise, and meet the goals by estimating the amount of time, money, and effort of the work. 

At least that is the theory behind the estimation, however, in reality when the problem is complex with high uncertainty then the estimation won’t be straightforward and accurate. 

In this article, I’m going to explain how we can be predictable without estimation. But first, we need to understand how to generate and read the Lead Time Distribution chart (AKA Histogram).

Let’s have a look at the following Lead Time Distribution chart, which represents all the works that one of my teams delivered, in the last four months.

X-axis: shows the number of days from when the work is committed until it’s delivered to the customer (Lead Time). Please notice that this is a range and not a single number. For example, the value of 10 shows all the works that took between 5 to 10 days to be delivered.

Y-axis: shows the number of works that fit into each range. For example, if you look at the first bar, you’ll see that 25 works took less or equal to 1 day or 65 works delivered between 1 to 5 days.

Now let’s dig into it with a little bit more details and see how we can read the chart. As highlighted on the chart, 70% of works are delivered within 10 days. If the service level expectation is 10 days then this means 30% of our customers’ requests were delayed. 

Lead Time rangeNumber of works delivered
0 – 5 days37%
0 – 10 days70%
0 – 15 days86%
0 – 20 days96%

How we can predict when a new work will be delivered to the customer? 

We look at this team histogram and based on what actually happened in the past we predict the future, and this is because what happened before, will most likely happen again. 

When a new request to the team, we can predict that if we start it today, there is a 70% chance that it will be done within 10 days. If this is not acceptable then we should start it 15 days before the expected delivery date which gives us an 86% chance that delivers at the right time. Sometimes there is a fixed due date and the request MUST be fulfilled on or before that date, in this case, we should start 20 days before then with 96% accuracy the job will be done at the right time.   

Now we can predict when the job will be done without estimation!! And we can spend our time on something more valuable. 

Histogram with long tail

Sometimes your histogram (Lead Time Distribution chart) has a long tail. Please look at the following chart.

As you can notice in the second chart, there are some works that took a lot longer and caused a long tail.

Long-tail means low predictability

 In the following table, I’ve compared the predictability of both teams and you can see that the team with a long tail has much lower predictability. If Team A (no long tail) wants to have +95% accuracy of the delivery date, then they should start 20 days before, which is 60 days for Team B with the long tail.    

Lead Time rangeNumber of works delivered (Team with NO long tail)Number of works delivered (Team with long tail)
0 – 5 days37%31%
0  – 10 days70%52%
0 – 15 days86%64%
0 – 20 days96%71%
0 – 60 days100%98%


Estimating the size of the knowledge works have been always challenging and had a negative impact on customers trust, people moral (blame game) as well as low-quality products. By measuring the Lead Time and how it’s distributed historically we would be able to be more predictable while we are predictable, in fact, we will be more predictable and this is because we predict based on what actually happened in the past rather than guess. In Team Kanban Practitioner and Kanban System Design courses, we will discuss the Lead Time Distribution and explain how this chart can help us to improve the system.


Orod is an Agile Coach, public speaker and Accredited Kanban Trainer, SAFe Program consultant, Scrum Master and food vlogger.

Since 2010, Orod has trained and helped many organisations in a variety of industries, to design sustainable kanban systems and support them to gradually improve their business agility by delivering the right work at the right time, without changing job titles or oranisation structure.

Published by Jason

Jason is an agile coach and trainer with 16 years experience applying agile principles and practices in a variety of industries and initiative types. Skilled in agile transformation and coaching, he is a professional motivated towards relentless improvement, inspiring agility and thought leadership to evolve leadership and teams to think differently and achieve great outcomes.

Leave a ReplyCancel reply