Comments on: Estimate Units http://mcherm.com/permalinks/1/estimate-units Adventures in Programming Fri, 02 Apr 2010 16:07:43 -0700 http://wordpress.org/?v=2.9.2 hourly 1 By: Doug L. http://mcherm.com/permalinks/1/estimate-units/comment-page-1#comment-21537 Doug L. Wed, 17 Jun 2009 23:00:31 +0000 http://mcherm.com/?p=268#comment-21537 Neither hours nor days. Use "ideal estimation units". Then, keep track. Measure your first few iterations, and you end up with a rough approximation of how many IEUs you or your team can accomplish in, say, a week. Neither hours nor days. Use “ideal estimation units”. Then, keep track. Measure your first few iterations, and you end up with a rough approximation of how many IEUs you or your team can accomplish in, say, a week.

]]> By: Eric B. Martin http://mcherm.com/permalinks/1/estimate-units/comment-page-1#comment-11317 Eric B. Martin Wed, 18 Feb 2009 01:24:16 +0000 http://mcherm.com/?p=268#comment-11317 In my experience, haggling over hours mostly comes down to, egos aside, perceived differences in implementation speed. If using an Agile development methodology, pick the higher of the two (or average them) and move on, after all, if you have extra time left over, you just tack on another task for the sprint. What I have found that works well for estimation comes in three parts (in order): Difficulty rating (Simplistic, Easy, Medium, Hard, Impossible) – Helps determine proficiency needed to complete and can indicate the accuracy of the estimate Time Estimate – In hours if the task definition is fine grained enough, ½ days if not Confidence rating (0% to 100%) - Confidence the estimator has in their estimate being completed in the estimated time – a low percentage means there are significant unknowns that could affect the actual implementation time - this item can be averaged over several items to determine over-all CR. In my experience, haggling over hours mostly comes down to, egos aside, perceived differences in implementation speed. If using an Agile development methodology, pick the higher of the two (or average them) and move on, after all, if you have extra time left over, you just tack on another task for the sprint.

What I have found that works well for estimation comes in three parts (in order):

Difficulty rating (Simplistic, Easy, Medium, Hard, Impossible) –
Helps determine proficiency needed to complete and can indicate the accuracy of the estimate

Time Estimate –
In hours if the task definition is fine grained enough, ½ days if not

Confidence rating (0% to 100%) –
Confidence the estimator has in their estimate being completed in the estimated time – a low percentage means there are significant unknowns that could affect the actual implementation time – this item can be averaged over several items to determine over-all CR.

]]>