estimating projects

Richard Esplin richard-lists at esplins.org
Mon Jan 9 22:53:20 MST 2012


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 <wadeshearer.lists at me.com> 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)


More information about the PLUG mailing list