Kanban and When Will This Be Done?

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.

Tags: , , , , ,

14 Responses to “Kanban and When Will This Be Done?”

  1. Pawel Brodzinski says on :

    I recently shared some insight how we’re dealing with estimates in our Kanban team. Same as you we base on cycle time.

    The tricky part here, and the one which should be stressed, is that you can deliver reliable estimates only as long as you don’t face many priority changes. One of cool things about Kanban is it allows frequent course adjustments. However it has also drawbacks – every time you put another thing on the top of todo list the rest of queue which is lower will be delivered later. Now, on the day 0 you don’t really know how many of these situations you’d face so depending on that overall schedule may slip pretty much.

    Yes, this is pretty natural, but still we’re often expected to deliver fixed dates no matter how vague scope is or how much it changes along the way.

  2. Pawel Brodzinski says on :

    Oh, and the link to the article which I forgot: http://blog.brodzinski.com/2010/05/kanban-estimation.html

  3. Dan Rough says on :

    Hey Dennis,

    Great post and very much in line with something that we do at 7digital in one of our teams, we use the data with a subtle difference and talk more about the risk involved in the estimate though. The nature of the Stakeholders for the team means that they need to make a commitment to delivering a set of functionality in a contract (though I am aware of other ways of drawing up contracts, it’s not something that has taken hold) and so the element of risk is important. The team manages that risk on a daily basis calling the commitment that they make an SLA which removes the sense that the estimate is binding which is often a problem with estimates, as I am sure you know.

    See this post I made recently on the subject, I’d be interested in your thoughts.

  4. Markus Andrezak says on :

    Hi Dennis,

    Great post, Going further I would even say that the exact delivery time of single features gets less and less Important the further you get in

    - value oriented prioritization
    - constant / continuous delivery
    - and the insight that a product is constantly built up from a flow or stream of features.

    Once you have set up such an environment it is paid back by the trust of your organization that a good product will exist in time. (And the Press Conference / Release will not Be destroyed by small missing details.

    Of course this is only possible w/ deep understanding and cooperation between PO and Team. But then it is plain beautiful and a constructive ‘politics’ free zone :-)



  5. Dennis Stevens says on :


    Thanks for your comment. I agree with your point that the more reliable you get the less people focus on the exact delivery time and more on how to collectively deliver value. And it is a beautiful thing – in sharp contrast to the blaming, CYA, “you get what you get when you get it” environment of many development team.


  6. Yuval says on :

    Dennis – Great Post!

    I intend to share this with groups I’m working with.
    It provides answers to one of the frequently asked questions about Kanban.

  7. Yuval says on :

    One complication around t-shirt sizing and effect on cycle times is around delivery cadence.
    If your kanban system has a sprint-like delivery cadence, it will affect cycle times and make them less accurate, so the groupings will not be as clear.

    Probably makes sense to measure cycle time up to the release activity, and add the frequency of the release activity to the “when will this be released” forecast.

  8. Scrumban when will this be done « Kanban at Agilesparks says on :

    [...] at 4:03 pm · Filed under Uncategorized Dennis Stevens wrote a wonderful blog post called Kanban and when will this be done where he talks about how to forecast done dates in a kanban environment and how kanban looks at [...]

  9. Dennis Stevens » Blog Archive » Kanban: What are Classes of Service and Why Should You Care? says on :

    [...] last post, Kanban and When Will This Be Done? was about using Cycle Time to make reliable commitments to the customers of your organization. I [...]

  10. Dennis Stevens » Blog Archive » Kanban: Negotiating and Managing Service Level Agreements says on :

    [...] my last couple of posts I have been talking about Measuring and Managing Flow in your Kanban system. With some simple tracking, you will pretty rapidly have an [...]

  11. Does A Kanban System Eschew Estimation | AvailAgility says on :

    [...] future (with natural variability). Dennis Stevens has recently written some great posts discussing knowing when we will be done, using classes of service and service level agreements to manage [...]

  12. Dennis Stevens says on :

    This is excellent Dan. I like the table you have presented there. I talk about the SLA in Negotiating and Managing Service Level Agreements. Your example with the data makes this approach very clear.

  13. Dennis Stevens says on :

    You are right Pawel. So Lead time is subject to this disruption. What we are calling Cycle Time (the time we start work until we deliver it) should be less subject to this disruption. However, if there are a lot of expedites and silver bullets it will also make the Cycle Time less predictable. From my experience, Expedites and Silver Bullets are typically emotionally driven more than pragmatically required. The lack of trust in our ability to make and keep commitments increases the frequency of these items. Being able to make reliable commitments in the Standard Work Item type dramatically reduces the call for expedites and silver bullets.

  14. Scrumban when will this be done | Yeret on Agile/Kanban says on :

    [...] Stevens wrote a wonderful blog post called Kanban and when will this be done where he talks about how to forecast done dates in a kanban environment and how kanban looks at [...]

Leave a Reply