In our book Why Plans Fail, we discuss something called the Planning Fallacy and, as is pretty apparent by its name, how it mucks with our ability to plan. It turns out that we’re quite unskilled at planning. As a former urban planning and large project manager, this was both a relief and demoralizing … and even frightening.Much of our lives are based on judgment calls - on making spot estimates about everything. So, let’s take a look at some estimates we might make:1. “I estimate that car three blocks away will not hit me if I cross the street now.”2. “I estimate these eggs have 2 more minutes.”3. “I estimate that this massive 15 million dollar project will be done in exactly 12 months and take exactly 300 people and will require exactly these tasks to be done in exactly this order each taking exactly this much time.”Which of these three stand the least chance of being correct?If you guessed 1 or 2, then you’re just trying to be wrong. It’s pretty apparent that #3 is a very large thing with many moving parts and a huge helping of unknowns. Yet we frequently estimate work for ourselves or others and then are disappointed when we are wrong.We are wrong for a variety of reasons:

We don’t understand the role of variation in our work
We are estimating before we’ve started the project and are simply underinformed
We are trying to meet a deadline that is shorter than the time it would take to create a quality product
We are trying to come in as a least-cost bid
We are trying to get work done while understaffed
During the project is snows, rains, tornadoes, floods, earthquakes, locust plagues, or other bizarre thing that seems to happen during every project
We don’t want to look “slow”
We don’t have time to do a thorough review
It is politically inadvisable to say what the real estimate is, so we give a lower one and hope to find efficiencies to make up the time
We think about “ideal” hours and estimate based on how long we think we could personally do the work if we were totally focused and never interrupted

This list could seriously go on for days.Personal Kanban is helpful here because we can begin to track the amount of time it takes to actually complete our work. There are two metrics here: Lead Time and Cycle Time.Lead time is the amount of time it takes to get a ticket from its creation to its completion. Cycle time is the amount of time it takes to get work from the start of actual work to completion.Key here is how we manage our backlog. In most of the Personal Kanban writing, we assume that the backlog is an open repository for all demands. If that’s the case, then it has no limit and we really can’t measure anything against it.However, if we set up something like the system below:Here we have a “backlog” which holds all our prospective tasks forever. So every project we might want to do, goals, whims, it’s all in there. In our “ready” column, however, we have a 7 ticket limit. That limit means that when something enters ready it is probably going to be moved to doing very soon.With this limit we can begin to gather planning-level metrics. So:Lead Time = [Date / time ticket moved into DONE] - [Date / time ticket moved into READY]This says, from the moment something hits my ready column, it takes Lead Time to be completed.Cycle Time = [Date / time ticket moved into DOING] - [Date / Time ticket moved into DONE]This tells us that when we start working on something, it takes Cycle Time to complete.With these numbers we start to see variation in our work. We will see it in a variety of ways.

Variation in the set - So we have a set of numbers now that show how long it takes us to complete tasks. Some of them it takes a long time to complete, others it takes a short time to complete. If we graph this, it shows the dispersion of task completion times we have had.
Variation in “like” tasks - Let’s say you do the same thing repeatedly. Like checking up on one of your large clients. Usually it is as simple as calling and having a quick 5 minute phone call. But sometimes it doesn’t go right. They have an issue, or maybe they’re just chatty, and you find yourself talking to them for an hour and a half. The task “checkin with client” was the same, but the amount of time it takes to complete it can change. Instinctively, we know this happens, but we never account for it in our estimates.
Unforeseen events - Let’s say you’ve designated on task to take 8 hours. You have a week before the deadline and all is good. The day before you’re going to complete it, there is a blizzard that keeps you from completing it for six days.

Most of the time, our estimates are wrong. Often it’s due to us simply not understanding our own work. We don’t understand how often we are interrupted, the role of variation in our work, or simply the work itself. With the kanban and Personal Kanban, we are able to see work as it happens, notice bottlenecks, and measure real completion time.As we see this, we are able to refine estimates on the fly.This is post #5 of the Elements of Kanban Series, click for the full list of 13.