Last week I blogged about how an estimate is not a guarantee. A small, but important, omission from that post was the distinction between an accurate estimate and a precise estimate.
Frequently accuracy and precision seem to be considered the same thing. The critical difference was highlighted when I went on an agile course run by Mike Cohn. He demonstrated the difference by asking the question of when your birthday was?
I could answer this question by saying it’s in November. This is accurate and in some cases might be a good enough answer, however it is not precise and certainly wouldn’t help if you were planning on organising a surprise party. However if I had said the 2nd December I would have given a precise answer, although completely inaccurate.
What I have learnt from this is that in software development it’s more important to focus on making an estimate accurate, rather than trying to be precise. I like the approach taken in planning poker where there are quantized buckets that your estimates can fit into. The difference between a story being sized at 1 story point and 2 is huge; the second is twice the size of the first.
However the difference between a story sized at 20 story points and 21 is insignificant. In fact, how can we possibly tell that one is marginally larger than the other? There is also a danger that the extra precision suggests a high level of confidence in our estimates, which, in my experience, just doesn’t happen in software development. In this case it makes more sense to estimate both at 20 story points and allow velocity to work its magic of how much work to take on during a sprint.
At the end of the day it is better to be imprecisely accurate than it is to be precisely inaccurate.