When I talk to people external to my team, I use this algorithm:
* Estimate in programmer days
* Round up
* Add 20%
* Times by two
* Increment the unit (days=>weeks, weeks=>months, months=>years)

Honestly, I like to use guesses at how many half-days would be required as the 
basis for story points. This is consistently inaccurate, but work well as a 
shared reference point.

I have previously used the Cohn Scale (0, 1, 2, 3, 5, 8, 13, 20, 40, 100), but 
it takes a while to have a shared expectation of what each number means. 
Explanation here:

http://www.scrum-breakfast.com/2008/02/explaining-story-points-to-management.html

This is a good article on the FogBugz technique of Evidence Based Scheduling:

http://www.joelonsoftware.com/items/2007/10/26.html

Good luck,

Richard

On Monday January 9 2012 22:08:38 Wade Preston Shearer 
<[email protected]> wrote:
> Anyone have any opinion or advice on various point scales for estimating 
> software development time? I've always done it in hours/days, but am going to 
> try and have my team switch to a scale.
> 
> Powers of 2 (0, 1, 2, 4, 8)
> Linear (0, 1, 2, 3)
> Fibonacci (0, 1, 2, 3, 5, 8)
> 
> 
> (we're using the scrum agile project management framework)

/*
PLUG: http://plug.org, #utah on irc.freenode.net
Unsubscribe: http://plug.org/mailman/options/plug
Don't fear the penguin.
*/

Reply via email to