How do I account for changed or forgotten tasks in an estimate?

Question

To handle task-level estimates and time reporting, I have been using (roughly) the technique that Steve McConnell describes in Chapter 10 of Software Estimation. Specifically, when the time comes for me to create task-level estimates (right before coding begins on a project), I determine the tasks at a fairly granular level so that, whenever possible, I have no tasks with a single-point, 50%-confidence estimate greater than four hours. That way, the task estimation process helps with constructing the software while helping me not to forget tasks during estimation. I come up with a range of hours possible for each task also, and using the statistical calculations that McConnell describes along with my historical accuracy data, I can generate estimates at other confidence levels when desired. I feel like this method has been working fairly well for me. We are required to put tasks and their estimates into TFS for tracking, so I use the estimates at the percentage of confidence I am told to use.

I am unsure, however, what to do when I do forget a task, or I end up needing to do work that does not neatly fall within one of the tasks I estimated. Of course, trying to avoid this situation is best, but how do I account for forgotten/changed tasks? I want to have the best historical data I can to help me with future estimates, but right now, I basically am just calculating whether I made the 50%-confidence estimate and whether I made it inside the ranged estimate.

I'll be happy to clarify what I'm asking if needed -- let me know what is unclear.

Answer 1

The book Waltzing With Bears: Managing Risk on Software Projects (by DeMarco and Lister, the Peopleware authors) has a terrific approach to this. Here's my reinterpretation:

Make an "everything goes perfectly" estimate. Of course, everything rarely goes perfectly, so that has a low likelyhood of happening, say 0.1 percent. In other words, only one project in a thousand will go perfectly to plan. This is what most people use as their "estimate" which is obviously insane.

Instead we should think of estimates as probability distributions. This "perfect world" estimate is the left most point on the estimate probability distribution.

Next make a "if things go about like that have gone for similar projects like this" estimate. This estimate helps you take "outside view" (http://wiki.lesswrong.com/wiki/Outside_view), escaping from the planning fallacy (http://wiki.lesswrong.com/wiki/Planning_fallacy).

Next make a "I'm 90% sure we'll be done by X" estimate. Be very, very sure you mean 90% sure. In other words, you expect to take longer than this estimate only once for every ten projects you do.

We can now use your first estimate as the 0.1% probability estimate and your second as the 50% probability estimate (season to taste) and the third as your 90% estimate, which will give you a nice curve.

Say your 0%, 50% and 90% estimates were May 1st, June 1st, and August 1st, then your estimate curve would look something like this:

     100 |                                  ......
         |                        ..........
% chance |                ........
of being |          ......
  done   |      ....
         |   ...
         |...
       0 +-----------------------------------------
          \           \           \           \
           May 1st     June 1st    July 1st    August 1st

Note how the probability's growth slows over time. If someone asked you for a 99.9% estimate in this scenario, it might be January 1st of the next year.

Answer 2

In a word - contingency.

Contingency is the amount you add for "other stuff" - the things you can't account for elsewhere in your estimate. Does SMc cover it in Software Estimating? I can't remember and my copy is at work (I'm on holiday answering this - how sad am I)...

Anyway, generally speaking there are three sorts of contingency I'd recommend looking at:

1) Risk specific contingency - that is where you identify a specific risk and add a certain amount of time to cover the potential overrun related to it. The first thing to be clear on here is what a risk is - it is something which may come to pass, which will negatively impact on the project, which is outside of your control.

This last part is critical - it's not just "things taking a bit longer than I thought", it's "the 3rd party scheduling module we've been told we have to use as it's a company standard might not be up to the task". The way you calculate how much risk contingency to add is the percentage chance the risk might come to pass expressed as a decimal (so 50% = 0.5), times the impact of that risk (so in the example say you need to manually write CRON jobs instead of using the scheduler and this will take 10 days, this number is 10 days).

So if there's a 50% chance of your risk coming to pass, and it will take 10 days effort to get round it if it does, you add 5 days. Add up all the values for all identified risks on the project and add it to the total.

2) Shit Happens Contingency - The best description I ever heard for it, even if it's not elegant. It's an IT project, shit happens. It never goes how you think it will, things take longer, get missed out and so on. Generally SH Contingency will be between 10% (absolute minimum) and 25% (though can be higher) with 15% being about typical, the exact level dependent on the level of uncertainty and general risk (moving goal posts, uncertain requirements and so on).

If your PM doesn't accept SH Contingency (and it's possible, he might have no experience of IT projects or be a blind optimist), then just add it to all the individual amounts. If he knows what he's doing he'll have a risk log of his own and love you for thinking about this stuff. Certainly if he has any sort of PM qualification (such as PRINCE2) he'll know about it.

3) Change Contingency - This is where you are fairly sure that the client will raise changes but don't want it to be a point of contention. Add either X days or X% and it goes into a pot for changes the customer raises. There are two ways of dealing with it: either you tell them about it and it's theirs to spend or you don't tell them about it.

The first way is best but needs a fairly educated and fair minded customer - things are classified as changes and he can spend his pot as he sees fit (based on you estimating things as they come up).

The second way you mention that it's a change but don't look to charge him extra. You do have to note all the things that you spend it on so if it does get to the point that it runs out and you have to go back to the customer and ask for more time or money and they say "hold on, I'm paying blah blah blah" you can point out all the things they've already changed which you haven't charged for as a sign that you're not being entirely unreasonable. It doesn't always work but it almost always strengthens your hand in the discussions.

None of those three specifically cover things you've forgotten but I think between them you'll fill a lot of the gaps you've got.

Answer 3

When asked for an estimate for a task, give high end estimate to team and have low end estimate for yourself, doing that you will always have time after task is accomplished to work on something that you might have forgotten to mention in first place.

Answer 4

Are you concerned that by adding the extra tasks, you will skew your historical accuracy? Or do you think that not including the extra tasks will skew the accuracy?

I think for best of the project, the tasks should be entered into tracking system. I'm sure the project lead will be able to offer a suitable explanation to management for discrepancies...