## Estimating with time and relative sizes

If you are estimating work, the chances are that you are on a gradual philosophical journey that starts with time-based estimates. Estimating how many hours, days, weeks and months a task will take is what I like to call “novice estimating”. Almost everyone knows how long these units of measurement are, which makes them very easy to use when you start estimating.

Over time though, the frailties of time-based approaches become apparent. When you estimate something will take 10 days, you can bet that on day 11 someone will be stood by your desk waiting for the finished product. The sad fact is that very experienced estimators fail to give a correct, precise and accurate estimates and they know that it just isn’t possible.

Actually, it is possible to give a 100% accurate and 100% precise estimate of how long something will take – but to arrive at the figure takes (amazingly) the amount of time the task takes to complete. The whole point of estimation is to try to predict how long something will take – and that means it is expected to give a number in return for an amount of effort that is many orders of magnitude smaller than the work itself. If it took you a day to arrive at a reasonable estimate for a two-day piece of work, it wouldn’t be worth the effort to estimate right? If it took you one minute to arrive at an estimate of 2 to 3 days, that would be an acceptable investment (or at least more acceptable than the first example).

But time-based estimates suffer from sounding too real. If you gave a range of 20-35 days, it would inevitably end up on a Gantt-chart with a 20 day duration (if you are using time-based estimates, I also assume you are using Gantt-charts and horse-whips). Time-based estimates also relate too closely to individual skill. What takes me one day might well take you a week (or vice versa).

So many intermediate and expert estimators use a more abstract method of estimating, which we’ll call “sizing”. Using t-shirt sizes or some kind of points-system to generate relative-sizes breaks the link between the size of the task and the effort or hours it may involve. Using relative sizes helps to smooth out individual differences and instead looks to group similarly-sized stories into themes. The idea isn’t to try and work out exactly how long something will take but instead relate it to a previous task of similar size.

For example, after you have got the weekly food shopping, washed the car and hung the washing out you could use these as benchmarks for deciding how long the hoovering might take. It definitely won’t take as long as the weekly food shop – so does it feel more like hanging the washing out or more like washing the car? To make the math easier, we might assign numbers such as eight for the shopping, five for the car wash and three for hanging out the smalls.

With our abstract numbers (that bear no relation to units of time) we can quickly sort out tasks into big buckets of other similar-sized work and behind the scenes we can work out how many tasks we might complete given an amount of time. We also find that once we venture beyond the smaller sizes, the reliability goes out of the window. If we’re using a scale such as the one described above, once we get to sizes over eight, we find that things are unreliable and the variation in the real effort of “similarly sized” tasks becomes un-workably volatile.

The points you assign should always relate to similarly sized work, not the people doing the work or the number of bank holidays taking place during the build. If you try to adjust the relative numbers to take other factors into account, you lose the relationship between similar sized pieces of work. Far better to adjust velocity, or apply a focus-factor or find some other way of adjusting your calculations that doesn’t place two similar items in different buckets.

In a mature relative-sizing environment the real value of estimating or sizing becomes the process of understanding the story, the tasks involved and breaking down anything that is too large. This leads to the next stage in the estimating journey, which is to get all the valuable parts out of the process without getting overly-bogged down in the numbers.

For quite a while now I have been leaning ever-closer towards a technique called “everything is a three”. The idea behind this technique is to stop trying to assign the correct number to each task, but to instead work on a task until it fits some arbitrary number.

If you used “everything is a three” to size a full valet on a car, it would clearly be bigger than a three (a three is hanging the washing out or hoovering remember). So it must be broken up until we have stories that are a three. We might say washing the car was one story and cleaning the inside was another. If each of these feels too big, we crack it open again. Now we have “shampoo and rinse car”, “polish car”, “hoover interior” and “polish interior surfaces”. If these all feel small enough, we stop. The process of breaking things into smaller parts normally leads to all the same questions and discussions as estimating or sizing, but with many additional benefits.

If we said that a full valet was a 13 point story, maybe that would just take too long and it wouldn’t even be worth doing it at all. Once we break it down into smaller parts, we have the option to stop when we have enough business value – maybe the hoovering is important but the polishing of interior surfaces isn’t. When we break things down small we can maximise on the work we don’t do. We can deliver some value much sooner, which gives us an earlier break-even. We also get better accuracy, as we know that the larger a story is the more volatile the estimate is.

The next logical step once you have mastered “everything is a three” is to just count the stories themselves, you’ll find that other than the scales, any graph you produce will look identical. This is really in essence a renaming and re-basing of the same idea.

You can go a step further and do no-estimates, but really this still requires the discipline of discovering the requirements and breaking things down to ensure we don’t make things that aren’t important – the “everything is a three” technique gets you everything you need with no waste.

Written by Steve Fenton on