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
_______________________________________________
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode