Friday, December 21, 2012
Value of Estimate as Value of Information
The claim of this post is that estimates are information that (should) reduce uncertainty about decisions that have economic consequences, thus they (should) have value.
Here is why.
A mantra of any Agile method is that you need to produce value, and you have to do it as soon as possible. A new mantra is that estimates do not provide any value. Thus you should drop them,
If doing an activity will take time T, and you add the time t for estimating T in advance, then the total time will be T+t instead of T. Thus, given that spending time t+T costs more than spending only time T, you should not estimate.
There is an argument for estimating instead:
Suppose that the stakeholder needs to select between two features F1 and F2 with values V1 and V2.
If their costs C1 and C2 are not the same then she could decide a trade-off, for example comparing V1/C1 and V2/C2. (max value, min cost).
The cost is the time, of course.
She actually does not know exactly the values V1 and V2, and the costs C1 and C2 neither.
She can be better than the technical team in "estimating" the difference between V1 and V2, but in the same way is the technical team that should be better than her in "estimating" the difference between C1 and C2.
So it must be rational trying to maximize the V/C having a discussion with the team about comparing C1, C2...
So the estimation provides value because it determines actions that have economic consequence (and the difference between those consequences is the value of that information.)
All this means, simply, that despite estimating has a cost (t), it conveys value (value of information) as any other team activity.
(Yes, but the economic consequence of the order in picking up the F1 or F2 first or not cold be less valuable if F1 and F2 need to be done both for sure, and nobody is going to use the product before both the features will be done. That's another story. If you think in this way for all the "already known" features F1, ... Fn of a Product, then all of this becomes a little bit unflexible, not realistic, and not... Agile anymore)
(book: How to Measure Anything, Douglasùùù W. Hubbard)