As software people we are often tasked with estimating how much work/time/money something is likely to require. I know that many of us feel this is difficult at the best of times, and often impossible. But is there a better way to answer the questions of how much and how long? And how harmful can estimation actually be, if the customer needs it?

I'd like to argue that story estimation, using story points or time or whatever else, is harmful. Also, I'd like to argue that it does not answer any of the questions the customer have with regards to how much.

Let's start with the question. In my experience the customer is usually interested in two rather different how much. One is a guidance on the cost vs. gain, I.E. to make an informed decision on if it's valuable to invest in something. The other is to answer the when will I get what I ordered question, I.E. wall clock time until I can use the thing I want or need. The two often gets conflated and mixed up in each other and this can be harmful. So let's look a bit closer at each in turn.

When we start to plan for something we usually want to know if the value it will bring will compensate for the cost it will incur. Neither value nor cost are always monetary. But we often describe them in monetary terms since we seem to find this easier to think about. When we look at the cost of custom-built software there are a couple of things we need to take into account to understand the cost part. It is the running cost, the development cost and the maintenance cost or cost of change. As we start a new project, or start a bigger change effort in an already existing system, we usually look mainly at the development cost. This is often measured in time. But this time is rather different from the wall clock time it will take until delivery. We use this time to understand the cost, not the when will we get it. Because of this I think it is directly harmful to conflate the two.

When we look at when something will be delivered we are talking wall clock time. I.E. from now, at which date can I expect to have this thing in my hand and start getting value from it. In contrast to the previous time figure we are now interested in days something will take. We have to take in to account all other activities that take place in the teams daily lives, which not all are paid by the price tag of the delivery. Holiday time, sickness time, company events and so on. This figure is actually rather uninteresting when we try to understand the cost of building it. But it may be key in other activities, and especially in prioritising what to do first. I.E. are there any parts of what we are to build that will give the customer value sooner, to shorten the initial delivery time even if the whole is not complete.

So, now that I've defined what questions we need to answer I'll dig in to how to do so. Let's start with the first question, how much will this cost?

When doing story point estimation we are usually too far into the work for this to be even interesting. We have divided up the work into bite size chunks and already made a significant investment by getting here. A more natural approach to answer this question is to use a technique that Dan North calls blink estimation. Simply describes it goes something like this: Gather a group of people, some who knows what the problem is, somehow will have an idea on how to solve it in a meeting or workshop. Depending on the size of the problem this could take anything from a couple of hours to one or two days. First make sure everyone understands what the problem is. Then think about how to solve it. When a rough high level solution is decided upon we want to have three estimated number out of it. They go like this:

1. If everything runs smoothly, with no interruptions or surprises (as it never does) this should not take longer than X. Keep in mind that this is not wall clock time but cost time.
2. If we don't encounter any big surprises it is likely that it will take Y.
3. If it takes longer than Z we will go home in shame and are obviously not very good at our job.

They will give us a range. The range gives us a clear indication of how risky the undertaking is, how complex it is and something real to work with when we look at regaining the cost spent. The likelihood figure is often not in the middle between shortest and longest. It can be anywhere between the two. This also indicates risk factors and how much is unknown.

Now to estimating time of delivery. This is where we spend a lot of agonising time in teams. Where we try to be better at something that we simply cannot ever become good at. Here I side with the people in the #NoEstimates community. We just should not do this. There are much better ways to calculate the likely delivery time than trying to estimate story points or days or hours on pieces of work. See each piece as just that, something we are going to do. See how long it takes for a number of items to move from todo to done (done being delivered to the customer). Look at how many more items there are and use the data from past work to say when they are all to be done. Over time the pieces will be about as large as what we have already done. We are quite good at sizing up work in same size chunks. And on most projects we have a time line which is longer than a couple of weeks (if it's shorter the customer usually don't care that much, it's almost already done).

Also, estimation tends to lead us astray. It puts a focus on the estimate. How many times have you stressed about getting something done, knowing you've said it will take X and now you should have been done already. And you cut corners which just slows you down, often both in the short and long term. It also makes the customer focus on the estimate, rather than the value the what should deliver. We simply start focusing on this thing which has not value to us rather than getting valuable work done.

The links provided will give you more in depth about each, Blink Estimation and #NoEstimmates. Please do read about it, and watch presentations where provided. I can especially recommend Vasco Duarte's NoEstimate talk from 2014. It should, hopefully, get you the seriously reconsider the need for story estimation.

If you have feedback or thoughts on this, please don't hesitate to ping me on Twitter. If you want help with this in your organisation, get in touch.