≡ Menu
Pawel Brodzinski on Software Project Management

The Kanban Story: Coarse-Grained Estimation


Recently I told you what a screwed way we chose to measure lead time in our team. Unfortunately I’ve also promised to share some insight how we use lead times to get some (hopefully reliable) estimates. So here it goes.

Simplifying things a bit (but only a bit) we measure development and deployment time and call it lead time (and don’t feel bad at all about that). So how do I answer to our customers when they ask me when something will be ready?

That’s pretty easy. If we talk about a single feature and there is no other absolutely top priority task, I take a look at the board to track down a developer who will be first to complete his current task and discuss with him when he expects to finish it. Then I know when we can start working on the new, super-important feature ordered by the client. Then it’s enough to add two weeks (which is our average lead time) and make some effort to look oh, so tired as I’ve just completed such a difficult task of estimation. Oh, I need to tell the customer when they’re going to get the darn feature too, of course.

This however happens pretty rarely. We try to keep our MMFs (Minimal Marketable Features) stick to their name which means they are usually small. This also means that described situations, when client wants just one feature from us, are pretty much non-existent. That’s why you might have noticed I didn’t take into consideration a size of a feature in described scenario. In the real life we usually talk about bigger pieces of functionality. What we do then is we split the scope into small MMFs and then use two magic parameters to get our result.

One of parameters you already know – it is an average lead time. However there’s one more needed. It takes 13 days for the feature to get from the left to the right side of the board, but how many features are on the board at the same time? I took a crystal orb and it told me that on average we have 4,5 MMFs on the board. OK, I actually did a simple analysis of a longer period of time checking our completed MMFs and I got this result, but doesn’t a crystal orb sound so much better?

Now, the trick I call math. On average we can do 4,5 MMFs in 13 days. Since I have, let’s say, 10 features on my plate I have to queue them. If I worked with iterations it would take 2,2 iterations (10/4,5) which basically means 3 iterations. But since we don’t use time-boxing I can use 2,2 and multiply it by 13 days of my lead time and get something about 30 days. Now I don’t start with empty board so I have to add some time to allow my team to finish current tasks. On average it would be half of lead time so we should be ready in, say, 37 days.

And yes, this is rough estimate so I’d probably go with 40 days to avoid being blamed for delivering estimate which looked precise (37 looks very precise) but was just coarse-grained estimate.

That’s basically what I went through before telling my CEO we’re going to complete management site for the product we work on in 3 months. Well, actually I didn’t told him yet, but 3 months there are. No less, no more.

Although this post may look as it was loosely coupled with the Kanban Story it is definitely belongs there. So go, read the whole story.

in: kanban

3 comments… add one

  • Zsolt September 3, 2011, 1:10 pm

    Hi Pawel,

    I know that it was a long time ago, but did the average lead time calculation help your planning, in other words was the project estimated properly?

    I had a problem with average lead times. For example I have these lead times for the same sized items: 6, 6, 6, 22, 6, 3,
    4, 4, 13, 2, 2, 4, 8, 6, 9, 14, 14, 15, 16, 2, 5, 33, 8

    Using the average here is a suicide, that’s why I’m wondering how did it work for you.


  • Pawel Brodzinski September 3, 2011, 3:36 pm

    Well, there is one thing more in this. Actually we ended up using Standard Sized Features instead of MMFs (see this post for reference).

    I think it happened subconsciously as many changes initiated by Kanban. Anyway, we limited variation vastly. About 9 out of 10 features fell into the range 8-16 days and for most of the rest we could easily point reasons why they are non-standard cases.

    Anyway what you can do is you can attach T-shirt sizing to your features. Then you should be able to sort them out: which are small (cycle time of 2-3 days), medium (3-8), large (7-15) and extra large (14+). Of course there will be some anomalies but you should easily reduce variation and improve your estimates.

    Another thing you can try is you can run Monte Carlo analysis on your data. It will use your track record and use all the results, from 2-day long to 33-day long (see this post as a reference).

  • Zsolt September 5, 2011, 10:01 am

    Hi Pawel,

    Thanks for the Monte Carlo reference, I’ll check it out.


Leave a Comment