Even though the word consult comes from Latin and French and has nothing to do with it, giving estimates feels closer to conning than advising.
Naturally we feel bad about this, we do not want to feel like con-artists. We want to feel like we are helping and in response to the embarrassing emotion of guilt, we banish the problem to another realm where we do not have to take responsibility for the inevitable estimate gone awry. It really is a pretty clever way of making ourselves feel better about the estimates that we give. You may break out your inner maniac’s laughter now. Go on, you know you want to, it is all right; for you are in the company of maniacs.
This rite of banishment is performed through the powerful, almighty word; oft used and abused, terms like rough estimates, story points, units of work, or anything that is not a direct reference to Time, are thrown around. Time becomes the elephant in the room, everyone is thinking about it, yet no one is addressing it. What context does this deep need of maintaining wiggle-room remind us of … ah, yes. The art of conning and the obsession with never giving absolute answers. Or, in the words of Bruce Lee, “Be like water, my friend”.
Surely every developer has had a discussion about what e.g. a story point actually represents. This is the bed we have made. Far too much effort has been put into creating abstractions in order to give the perception of more accurate estimates of length. That sounds like a paradox in itself; we make something abstract, Time, and make it more abstract, Points, in order to talk about it as absolute.
-“Huh?”
That discussion about what the estimate means is a metaphorical train running full-tilt which if you get in front of, or find yourself in front of, you will have a Bad Time™. Eventually though, what happens is that everyone just kind of stops talking about it, externally accepting that it represents nothing.
Internally however, the conflict rages on. Every time the question, “How long will this take?”, is raised, an attempt to estimate length through conversion of abstract terms into some-what more concrete terms is made. This can lead to near Olympic-level mental acrobatics, which while impressive, is completely useless when pressured for an explanation on how the estimate was arrived at.
Especially a few weeks down the line, when the explanation of the acrobatics makes no sense at all because one or more factors changed between then and now. Much like dodging a bullet you have made an assumption about being fired in the future but never was.
Maybe we should strive to be plasma instead, existing in a state neither fluid nor solid. Flexible estimates? Fixed estimates? Pshaw. Plasma estimates!
Though if history has taught us anything, it is that just changing the terminology will not work in the long haul and this fanatical devotion to avoiding Time as a unit for measuring duration is actually more harmful than helpful. The nature of an estimate is that of a guess, so instead of making us better at guessing, which we have been trying for a while now, perhaps we should not make important plans based on guesses at all.
Consider this. Someone asks you how long it will take to drive to Paris from Oslo by car. You think about it for a while. You study a map. You create a mental model of the problem and apply your own unique problem-solving framework on the model and prepare your solution.
You are now ready to present them with your estimate on the trip’s duration, and so, you look them in the eye and say,
-“18 bananas.”.
/v.
The Iterate Blog 
The latest release of the Thoughtworks Technology Radar puts “Velocity as productivity” in the “Hold” category: http://www.thoughtworks.com/radar/#/techniques/705
An interesting read and comment on the whole use of story points etc. and the measue of “velocity” in a team I think.
T: Så hva er problemet med at prosjektleder vil ha estimater på oppgavene?
J: Det er vanskelig (umulig) å gi gode estimater, før vi har begynt å jobbe med oppgaven.
T: Hva er et eksempel på et estimat du kan gi? Er det et antall timer, dager eller uker?
J: Timer
T: F eks 16 timer?
J: Ja
T: Hvordan vet du at det tar nøyaktig 16 timer?
J: Det er det som er problemet. Jeg vet ikke. Det er bare et estimat.
T: Så du lyver til prosjektleder?
J: Vel, nei…tja kanskje…
T: Så hvordan ser estimatet ut om du skal være 100% ærlig?
J: Fra én dag til to uker. Kommer an på.
T: Ok, så hva om du sier det til prosjektleder?
J: Da sier han sikkert at det er for stor usikkerhet og ber meg estimere bedre
T: Hva skal da til for at du kan estimere med større sikkerhet
J: Mer tid. For å være helt sikker, må jeg implementere oppgaven helt ferdig
T: Så hvorfor ber du ikke om mer tid?
J: Det får vi ikke, fordi prosjektleder skal rapportere videre til sine ledere
T: Ok, så hva er da estimatet?
J: ? Mellom én dag og to uker?
T: Ja, hvis ikke ønsker å lyve igjen. Og hva tror du skjer om alle fortsetter å være like ærlige?
J: Vi får mer tid til å estimere eller vi blir enige om at den beste måten å redusere usikkerhet i estimater er å begynne å jobbe med oppgavene.
T: Høres det greit ut?
J: Ja.
T: Fint. Lykke til!
I don’t see it in quite the same way. Yes, we choose some abstract, but consistent way of estimating effort. Then we track actual performance over time, then we can, after only a sprint or two, have a surprisingly realistic estimate of future work.
Initially – when setting the project, we may have little real idea. However, once in about a month, we can give a very acurate estimate. Now it may be that management don’t much care for this – but consider this – what are the alternatives?
Your logic applies regardless of the unit we use, be it Time, Story Points, or Unicorns. The word “consistent” is key here.
So why do we use abstract terms when we can give accurate estimates?
Although I don’t think estimations are worth anything (I prefer working a more kanban-ish style, where you always work on the most important thing), when I have to work in an environment that requires estimation of some sort I think the points instead of time units gives a useful detachment from the tasks at hand. It makes me think about how hard is this task on a scale from 1 to ?, and not how long it would take me. I’m usually much more correct when it comes to the difficulty than the time needed.
It also has the bonus effect of not confusing estimates with deadlines, which happens quite a lot of you specify a time.
A hacky solution for a suboptimal development process =)
Agreed. The only caveat is that I have yet to see a kanban-ish style work in a heavily project-oriented organisation, and I think the problem can be reduced to “project vs. product”-mentalities.
I think that organisations that realise that they are building a product and have a systematic approach to incrementally growing it do a lot better than the typical project-based organisation which usually winds up with blown budgets, time constraints and code tainted by shortcut after shortcut … but that is another post entirely. 🙂