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

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.

-
Multiply by 3 (programmers.stackexchange.com/questions/41004/…) –  blueberryfields Feb 1 '11 at 17:21
I think I'm going to need to give an example of how I am doing these calculations as well as the problem I'm trying to solve. I don't have time at the moment, but I'll get to it as soon as I can. –  Andrew Feb 2 '11 at 2:41
In scrum you do not give out time estimates; you give story points, which give others an idea. You also do not size bottom-up. You do not need to - the velocity is a vague thing. –  Job Feb 2 '11 at 4:11
@Job We're not a scrum shop at this time. Also, unlike what another answerer has suggested, I have found so far that the bottom-up estimates have improved my estimation accuracy, largely by vastly reducing the number of forgotten tasks during task-level estimation. –  Andrew Feb 2 '11 at 5:05
@blueberryfields - multiplying only by 50% should be enough, at least in a company with many hierarchical levels, where each adds its own overestimation factor. –  mouviciel Feb 2 '11 at 9:07

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...

-
I could just wait until tomorrow and tell you this in person. :) I'm more concerned about history's inaccuracy if the extra tasks are not somehow included. Clearly, missing a task during task estimation is a "miss" regarding accuracy -- but which accuracy figure? The one I actually use in a quantitative sense is whether my actual task performance for each task was within the predicted range. The other, more qualitative, measure is how often I meet my 50%-confident single-point estimates. Too far over or under 50%, and I should adjust "expert judgment" for future 50% estimates. –  Andrew Feb 2 '11 at 5:02

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.

-
Thank you for your answer. You raise interesting points. I already incorporate these three items in various ways in my estimates. Your first type, I have found, can typically be articulated and associated with one or more tasks. The second type just gets incorporated into my task-level range estimates: I'm not allowed to have an extra item for it (we've debated it, and for now, that's policy on our team). For the third, internal clients accept that changes will increase our estimate, and external clients have that in writing, so we're not supposed to consider changes. –  Andrew Feb 2 '11 at 2:33
As to whether McConnell covers contingencies, my copy is also at work, so I'd have to check. I think what I am asking is how to account for missing/changed tasks when computing history data to inform the next estimate as well as where to assign the hours in TFS, since a contingency task is normally not allowed in our group. –  Andrew Feb 2 '11 at 2:36

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.

-
Thanks for the answer. The method I've been using already allows me to do what you seem to be proposing, however, but it also takes into account (indirectly, by using a historical accuracy percentage) my past success with my estimates in order to generate the percent-confident estimates desired. What I am asking, though, is how to incorporate missed tasks into that historical accuracy when the accuracy is basically calculated by whether or not I finished a task within the range I used for my original estimate. –  Andrew Feb 1 '11 at 19:08
@Andrew, if I'm understanding you correctly, the "missed tasks" are accounted for by the less than 100% probability of being done at a given time. If you've done lots of projects like the current one, your curve will quickly slope from 0% to (say) 90%. That's because you have a high confidence of there being few missed tasks. If you have a low confidence, then the slope will be much more gradual. That goes for any reason, not just forgotten tasks, but other risk factors as well. –  Benji York Feb 1 '11 at 19:39
Yes, the missed tasks do get covered in the aggregate by the task-level ranges, which figure into the confidence levels I give out. I calculate those levels using a method McConnell proposes in Chapter 10 of Software Estimation, as I said before. I'm primarily wondering how I account for these missing or changed tasks in TFS hours reporting as well as how to include these hours when calculating my historical accuracy. –  Andrew Feb 2 '11 at 2:40

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.

-
Thanks for the answer. The ranges I come up with do, as a whole, tend to allow me enough time to add forgotten tasks without missing the estimate for the whole project. My question speaks more to using this information in the calculation procedure I am using from the McConnell book. –  Andrew Feb 1 '11 at 17:51