emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Carsten Dominik <carsten.dominik@gmail.com>
To: Mike Gauland <mikelygee@gmail.com>
Cc: emacs-orgmode@gnu.org
Subject: Re: Estimate ranges in column view
Date: Fri, 18 Jun 2010 09:04:10 +0200	[thread overview]
Message-ID: <10E98231-262C-45D4-82A2-2B660068A55E@gmail.com> (raw)
In-Reply-To: <loom.20100617T213846-275@post.gmane.org>

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

  reply	other threads:[~2010-06-18  7:50 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-17 20:06 Estimate ranges in column view Mike Gauland
2010-06-18  7:04 ` Carsten Dominik [this message]
2010-06-22  2:36   ` Michael Gauland
2010-06-30 13:40     ` Carsten Dominik
2010-06-30 18:19       ` Michael Gauland
2010-06-30 20:29         ` Juan
2010-07-01  7:55         ` Carsten Dominik
2010-07-19 11:57     ` Patchwork: Patch 65 Accepted Carsten Dominik
2010-07-19 12:03     ` Estimate ranges in column view Carsten Dominik
2010-07-20  9:53       ` Michael Gauland
     [not found]       ` <BC256B00-E893-4B6D-8C0D-855F7ADFF093-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2011-11-15 15:14         ` Sebastien Vauban
2011-11-24 15:44           ` Sebastien Vauban

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=10E98231-262C-45D4-82A2-2B660068A55E@gmail.com \
    --to=carsten.dominik@gmail.com \
    --cc=emacs-orgmode@gnu.org \
    --cc=mikelygee@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).