Estimate Units

When you estimate tasks, should the estimates be done in hours, or in days?

As I see it, the big advantage of estimating in hours is that if you THINK in hours, you tend to get a more accurate estimate. There are lots of development tasks which will seem like they should take “no more than 2 days”, but if you think about all the individual steps (I have write create the page and the new service. And the stored procedure. And I’ll have to get a security review and a code review. And I have to remember to do the unit tests. Oh yes, and save time for bug fixes), the total comes out a big bigger.

As I see it, the big advantage of estimating in days is that it’s quicker and simpler. If you team is sitting there arguing whether a task is 3 hours or 4 hours, then you’re wasting time — after all, development estimates are never THAT accurate anyway: we always need to allow for the unexpected.

Considering these, I could be persuaded to do it either way. What is NOT useful is to think how many days it will take, multiply by the number of hours per day, then spend time arguing about whether it is one more or one less than this number.

Comments

2 Responses to “Estimate Units”

  1. Eric B. Martin on 2009-02-17 9:24 pm

    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.

  2. Doug L. on 2009-06-17 7:00 pm

    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.

Leave a Reply