What do you do when you have to give a time estimate on fixing a bug, when initial investigation/debugging proves inconclusive?

Question

Your project manager says you must fix this bug, and asks you how long it will take. You spend some time tracing through your code, and inspecting it for defects, and don't manage to nail down any causes. Your project manager insists on a number from you, and won't take unknown for an answer. So what would you have said?

Answer 1

Sometimes you just have to say,

"I can't give you an exact time frame yet. Let me keep investigating and I'll let you know as soon as I can give you a valid estimate."

I think it's far worse to make something up to please mangement and then not make the deadline.

Answer 2

Fixing bugs is generally something that goes into the testing phases of a project, which should not try to schedule things by task. If the bug is in production, any time spent on it should fall outside the scope of scheduled project activities.

You have to explain that until you know what the problem is, there is no possible way to know how long it will take to fix it.

Project management's role in bug fixing should be limited to prioritizing the bug, and then checking progress, not trying to fit it into a Gannt chart.

Answer 3

You give an insane time-frame as an answer.

"Two months".

"TWO MONTHS!!??"

"You can have 'I don't know', or you can have 'two months'. Your pick."

Depending on how contentious this gets, it is best to do this via e-mail. Some project managers (especially if you are consulting) will just make something up if you do this. The ideal outcome is "fine, keep working on it and keep me posted daily on progress".

Answer 4

I love asking my PM, "How long does it take to find your keys when you lose them?".

Honestly it depends on how critical the bug is and how many critical bugs you have. If this is THE high priority bug, then you keep troubleshooting and keep the PM informed. If this is not the critical bug, then it should be common sense to your PM that you can mark this one as "expensive to fix" and come back to it when he can allow more time in the schedule.

There has to be a level of trust from the PM for your estimates or this situation will become common. However you handle this - you will be setting the expectations for the future.

Answer 5

I love asking my PM, "How long does it take to find your keys when you lose them?".

I love that! I will definitely use that one.

Answer 6

If the PM won't take 'don't know' for an answer, then I would suggest that you tell him that you are not done with your analysis yet. And if he asks how much longer the analysis will take, you can tell that you don't know. :)

Answer 7

The problem is most managers have to have a solid answer in hours. They have to fill out all the project plans and time lines, and cannot just have an "I don't know" for an answer.

So you have to come up with a real estimate, even when you have no clue.

There is a formula for this:

[Best case time frame] + [worst case time frame] / 2 = [time estimate to fix]

So 1 hour for best case + 40 hours for worst case = 20.5 hours estimate

Variations can be used to weight one way or another, normally after using the formula for awhile and learning which way it normally leans for your systems and ability to estimate.

Edited to include Wedge's correction:

---

x*[Best case] + y*[worst case] / (x+y) = [average estimate]

---

Of course this all depends on your knowledge of the systems in question and the ability to give good best and worst case estimates.

To really answer the manager's question, give him the formula estimate and the worst case; don't mention the best case.

Answer 8

I come across this as well, so I was looking forward to the replies to your question. But I think there has to be a better response than "I don't know", or "Two Months", or whatever.

In a related question, what about if this was a new feature for an application that is in production. You need to come up with an estimate for the customer so they can budget and schedule accordingly, or maybe even pass on the feature if it's too costly.

Whether it's a bug or an enhancement it's still the same problem. You're trying to estimate something that you can't pin down precisely. What I try to do is to find something else in the project (or another project) that is similar, and then go back and see how long I spent working on that. At least you can give an estimate based on past performance rather than just a wild guess.

With any estimate there is also an associated risk or unknown factor that should be considered. If this bug is exactly like another you've already fixed, then you know with little uncertainty how long it will take to fix. If it's not like anything else, the best you can do is to come up with a generous estimate, and then attach a high risk to it.

Answer 9

@RJBrady: It usually takes < 30 mins before I find my lost keys. In 30 mins, I can turn my entire house upside down.

The PM's request is neither unusual, or ignorant. You should be able to give an estimate, with some degree of precision, on tracking down and fixing the bug - or you're probably unqualified to understand and fix the bug in the first place.

If you don't know the cause yet, estimate how long the end game of your troubleshooting plan will take (you do have one, don't you? You're not just going to wave dead chickens around, are you?) and add a reasonable worst case fix in. Give the numbers separately.

Answer 10

You can't properly cost for investigating and fixing bugs ahead of time. You can only prioritize or budget for time spent bug fixing. If you really have to you can break things down into pieces. E.g. X number of hours to determine or rule out if the bug is due to Y, etc.

Answer 11

@Carlton, this is a somewhat reasonable way of approaching things but your formula is incorrect.

If you want to apply weights for assuming the best/worst is not 1:1 you can use this formula:

x*[Best case] + y*[worst case] / (x+y) = [average estimate]

Even better, just give the best and worst case estimates as a range (e.g. 1-3 days) or as an estimate with an uncertainty range (2 +/- 1 days).

Answer 12

@Wedge, thanks for the correction, I edited my original to add in.

Also, you can't give the best case scenario - that is all the manager hears and acts on. If you tell them it could be one hour, could be a week, that is not information they can use other than to come back in an hour and see if you are done, frustrating all involved.

Best thing to do it tell them "The average time to fix a problem in this system would be 20 hours, but it could take up to 40." Then after you are most way through your 20 hours (if not completed), you can update them or push out the time line if needed.

All this is is a rough way to come up with a number that cannot be known with certainty.