Re: Estimate ranges in column view

[Carsten Dominik <carsten.dominik@gmail.com>]

Hi Mike,

On Jun 17, 2010, at 10:06 PM, Mike Gauland wrote:

> When planning my work, I estimate the effort required as a range,  
> rather than a
> single value. That is, instead of estimating a certain task will  
> take 4 days,
> I'll use a range of 3-5 days. If I'm a bit less confident I know how  
> long it
> will take, I'll use a wider range (e.g., 2-6 days).
>
> When I first started doing this, I switched from using a single  
> 'Effort' column
> in org mode, to two columns (Effort_Low and Effort_High), simply  
> summing each
> column to get an estimate for a composite task.  However, this  
> magnifies the
> level of uncertainty in the estimate. The final 'Effort_Low' value  
> tells me what
> to expect if everything goes optimally; 'Effort_High' provides the  
> extremely
> pessimistic view.
>
> More realistic summaries come from considering the range of each  
> pair, using the
> combined statistical variance in each (low, high) pair to determine  
> the variance
> in the final value. This is the method used by LiquidPlanner, for  
> example.
>
> I've been mucking about with org-colview.el to automate this  
> calculation for me,
> and am quite pleased with the results so far. I've approached this  
> by adding a
> new summary type ("est") to org-columns-compile-map, and extending
> org-columns-number-to-string and org-columns-string-to-number to  
> convert ranges
> to and from strings. This lets me populate an 'Estimates' column  
> with values
> such as "[2 4]", and specify a summary type "est" to have the  
> algorithm
> described above used to produce the final estimates.
>
> I have two questions for the list:
>
>  1. Is this the right approach, or should I change the behaviour of  
> the
> existing EFFORT property?

Changing the existing EFFORT property would require more changes in  
other places for example in the agenda filter that filters by  
estimated effort, or maybe also in  code that helps to set/change the  
effort property.  So to make this fully work with the existing EFFORT  
property would probably require a lot more work.

>  2. Is this something others would find useful?

I like the idea of variance calculation for this purpose.  So I would  
be inclined to take a patch that will introduce this new summary  
operator.

Depending on how much code this is, you'd also have to sign the papers  
with the FSF (unless you have done so for Emacs already).

To complete the patch, you could make things easy for my be providing  
a change to the manual, and by also doing the corresponding changes in  
org-colview-xemacs.el.  But neither of these two would be required for  
acceptance.

Cheers

- Carsten