Posts Tagged ‘Estimating’

Kanban and When Will This Be Done?

Posted on June 7th, 2010 by Dennis Stevens  |  14 Comments »

A question that comes up a lot in Kanban is, “How can I know when this feature will be done?”.  First off, it is important to understand what makes estimating unpredictable – and then what steps Kanban presents to address this. Estimates are unreliable because the inherent variability work is compounded by the lack of flow in most teams and destructive behavior caused by fixed point estimates. Kanban, through a few simple techniques, a little bit of math, and the decoupling of planning and scheduling will give you the ability establish accurate estimates with minimal effort.

Cycle Time

The key metric we will use for estimating is Cycle Time. Cycle Time, in most Kanban and Lean contexts, is the time between when the team starts working on an item and when the item is delivered. imageCycle Time is what is interesting to managing (whether managed by management or self managed) the team. This metric becomes a key management metric to reduce variability in the system, make reliable commitments, and provide insight into whether improvement efforts are delivering expected results. We are going to talk about using Cycle Time to make reliable Due Date Performance commitments.

Cycle Time is easy to capture. When a card is pulled into the first work queue – enter the date on the card next to Start. When the card is moved to the last queue, enter the date on the card next to Finish. Cycle time is Finish Date – Start Date. At the end of the week, when you pull cards off the board, capture the cycle time for each card into a spreadsheet or whatever tool you are using for tracking.

Distribution Curves

What you will most likely find after you have captured a little data is that lead times fall in a distribution that is skewed to the right. This shows the variability in the work that you perform – there is some absolute limit on the shortest time the work can take – but there are a lot of ways it takes longer. imageTake the Cycle Time data and find the Mean and the Standard Deviation. Then set the expectation to the Mean + 1 Standard Deviation.

In this chart the work items are taking from 5 to 15 days. The Mean is 8.6 days and the Standard Deviation is 2 days. You can set a Due Date expectation 11 days and and be sure that you will hit this date about 80% of the time without changing anything you do. So that’s the policy, we will deliver work within 11 days with an 80% due date performance expectation. Over time, we hope to be able to improve the 80% and the 11 days.

There are a few nice things about this Cycle Time number. It takes a lot of complexity into account. Your Cycle Time calculation will have already incorporated the impact of rework while in the system, the typical impact of disruption from expediting, and the impact of waiting in the ready/done queues.

What about the 20% that will be late? There are a couple of things you can do. First, you will begin to be able to identify early which stories are going to be late. These will be ones that are more complex or end up with lots of rework. You can address these with capacity, prioritizing and/or communication to the customer. Addressing it with capacity means swarming on the task to bring it in closer to the due date. Addressing it with prioritizing might mean moving the card up higher in the stack then one that is likely to be done early. The cost of swarming and prioritizing means that another card might be delayed – but if you are thoughtful about prioritizing and swarming you won’t cause delay outside of the Due Date promise. For some cards, you will communicate to the customer that the card will exceed the due date performance expectation – while not optimal this is within your delivery commitment as long as it doesn’t happen more than 20% of the time.

T-Shirt Sizing

Many teams are dealing with work of various sizes. If you do a frequency analysis of your data you will probably see clusters of data. imageIn the picture below we have three clusters.  Rather than spending significant time in complex assessments to support estimating, the team can rapidly assign tasks into these clusters. We call this T-Shirt size estimating. Cluster like work into XS, S, M, L, and XL. You may decide that you don’t accept XL tasks without decomposition or require breaking them down. Then determine estimates for each size based on Mean + 1 Standard Deviation for each of the clusters. You can determine some simple process for assigning work into one of the T-Shirt sizes.

This won’t give you perfect estimates. Perfect estimates are almost impossible to determine. Additionally, Cycle Time Variability is probably impacted more by variation in the system like waiting and rework then anything else. It is impossible to determine the impact of the system by more deeply analyzing the task. With T-Shirt sizing and Cycle Time, you can get as accurate results in minutes as could you do in months. While not perfectly accurate – it’s as meaningful as anything you can do.

Schedule a Release

One of the interesting concepts in statistics is the concept of Regression Toward the Mean. What this means is that when you bring a lot of estimates together, you are likely to  have a final result where the average over time is close to the historical average. One example of this is driving to work. If you were asked to plan how long it would take to get to every stoplight on the way to work exactly, this would be impossible. But you have a pretty good idea what time you need to leave home each day to arrive at work at the right time.

Because of regression toward the mean and the actions we can take based on the visibility Kanban provides us, using T-Shirt sizes and cycle time to schedule a release will result in a pretty accurate estimate – and the cumulative estimate will be more precise than any individual estimate.

Decouple Planning and Scheduling

From a human nature standpoint, data can be a dangerous thing. The way we often couple planning with scheduling of resources is an example of this. With the way we have historically run projects, we put all the estimates together and then hold the team accountable to each individual estimate. This is unreasonable because we know that the estimate represents a range of possible outcomes. Five problems arise when we tightly couple estimating and scheduling of the work.

1. Bludgeoning: If we produce point estimates when outcomes are probabilistic – and then hold people accountable to hitting each individual estimate we are going get value destroying behavior. Bludgeoning people when they don’t hit 80% estimates means we are going to get 95% estimates. In most cases, the 95% estimate is about twice the duration of the likely outcome. This puts a lot of padding into the system.

2. Sandbagging: Another destructive management behavior when we couple planning and scheduling is accusing the team of sandbagging. This happens when the team delivers something in half the time of the estimate. Management will often want to go back and cut the “excessive padding” out of the rest of the estimates. First off, management drove the sandbagging behavior. Secondly, we know statistically that most work should be delivered earlier than an 80% or 95% estimate. The team learns not to deliver early because management charges them with sandbagging. So teams don’t deliver early and consume time that, on average, we need to accrue to the project.

3. Parkinson’s Law: Typical management techniques result in the team delaying delivery until the last moment. One outcome is that work expands so as to fill the time available for its completion. This is problematic because it leads to gold-plating of work that increases downstream efforts. It also ensure we don’t deliver a task that could be delivered early doesn’t get delivered early.

4. School boy Syndrome: The other behavior spawned by this is that the team doesn’t start as soon as possible because they wait until they think they need to start to deliver. This often means the team will start in time to deliver on the likely outcome – but deliver late when the task turns out to be more complicated or runs into a delay.

5. Murphy’s Law: If something can go wrong it will. We know that some work will take much longer than other work. This is Murphy’s Law. The behavior that arises from coupling planning to scheduling combined with Murphy’s Law ensures that projects will be delivered late – even against a 95% estimate. It is said that the losses accumulate and the gains are lost.

Kanban Helps Reliably Determine When Work Will Be Done

We can’t precisely predict how long work will take. Estimates represent a wide range of possible outcomes. In traditional project management, we ask for unreasonable estimates and then manage the work in such a way that we guarantee the project will be delivered late. Additionally, late delivery of work is as often driven by behavior that inhibits flow as the uncertainty around the work effort.

In Kanban we use Cycle Time data derived from the performance of the system to plan when work will be done. Then we decouple this planning effort from work scheduling – using the Kanban board to focus the team on flow. Kanban provides the team opportunities to make capacity and prioritization decisions that help address the innate variability of the work being performed to deliver within the policy. Cycle Time estimates, combined with limited WIP and a focus on flow, helps Kanban helps deliver predictable outcomes.