What techniques are available to calculate the accuracy of ranged estimates, on units of work that may be irregularly re-estimated? The evaluation should account for estimates made on behalf of another, and count those toward the estimator's rating.

Our tooling allows and encourages us to enter ranged estimates at the 80% confidence level, but critically we can't get the feedback that tells us we're estimating too high/low/wide/narrow etc. Without which, we cannot improve.

  • 1
    Do you collect actuals? Won't these values, if they are within your estimated range, validate that range? – David Espina Dec 20 '17 at 13:59
  • @DavidEspina yes; the problem is how to compare estimates made early on with those made closer to the end of the work. There should be some kind of weighting that can be formalised & used in an automated summary. – Robert K. Bell Dec 20 '17 at 20:58

A) Include more aspects into estimation

One thing that might help you estimate each task for effort (sheer amount of work), difficulty (amount of thinking) and risk/uncertainty (how much can go wrong). Then let those assessments guide your estimation.

B) Keep your estimates but adjust them

The FogBugz approach. Estimate normally, record how long it actually took you and let a computer program use that information to auto-translate all your future estimates. I was incredibly taken with this idea when I first heard about it. Unfortunately logging all those estimates AND actual times is laborious.

C) Have more experienced estimators do all the estimating

I've read of experiments where they've found that more experienced developers tend to create more accurate estimates even when they are not the ones doing the actual work. This has the downside of putting your best workers doing most of the chores. And those who are not good at estimating have no way of getting better at it.

D) Estimate in relative values

People tend to better at comparing tasks relative to each other than at predicting absolute time required. You still need to track how long it actually took you.

E) Simplify feedback

For B and D, tracking actual time only for batches of tasks greatly eases the administrative burden and still gives you some information of "when I estimate X points/hours that tends to equal around Y hours". If you don't end up comparing estimates with outcomes you will never get better. So a process that produces data with less precision is preferable to a process that produces no data because it's too inconvenient and people don't follow it.

If you put all of it together you get something like this:

  • When you estimate your tasks, do it together. That way more experienced team members can steer the rest towards more accurate estimates and less experience team members can still practice this skill and get feedback
  • Cultivate a more conscious awareness of the scope, complexity and risk
  • Use relative values to break free from the thinking "If I say X hours I need to be done by Y!"
  • When you did a bunch of stuff, sum up their respective estimates and relate them to the time it actually took you. Do this regularly to get empirical data on how your estimates tend to correlate to hours/days. Ensure that your blocks are large enough to buffer outliers short but enough to get a good body of data.
  • This is a little more high-level / abstract than I was looking for. Good answer though. – Robert K. Bell Dec 20 '17 at 21:03

Your Answer

By clicking "Post Your Answer", you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.