Bug Fixing Time Allocation

Question

We've been asked by a client to give us a time estimate on each and every bug we have.

Though we do have a set schedule for bug fixing and have allocated time for it, we don't have a time allocation on each of the bugs we have. Simply, we have prioritized our bugs and have ensured that Highest priority bugs will be fixed in the time allotted.

I'm not a fan of allocating time to bugs, simply because:

1. It usually is inaccurate. It's very difficult to figure out how long it would take to fix.
2. Waste of time.
3. Affects code quality
4. Creates more bugs in the long run (We may miss certain things in our attempt to complete it by the deadline).

How should we tackle this issue where we don't want to provide the number of hours per bug, but just a time frame as to what bugs will be fixed?

How do you allocate time to your bugs? Is it effective? Worth the time and effort?

Answer 1

The only answer I can give is to be extremely conservative. Guess how long it will take, and multiple your guess by four. Use that as your estimate. As you said, it's very difficult to figure out how long things will take to fix, and it's better to say it will take longer than it actually does than to be caught "breaking your deadline" because you weren't conservative enough.

Answer 2

It should be the same as estimating any other task you have. Split it up into the smallest tasks possible and estimate those as accurately as you can with padding for the unexpected. Then give them a range so you're not pinned down to a specific date on tasks that are not well-defined. There is no difference between estimating time to fix a bug and estimating time to implement a feature with nebulous requirements.

Answer 3

You're right, estimates are usually inaccurate.

Maybe you want to ask them how much each bug costs them if it goes unfixed. Then you can perform the appropriate computation for figuring out if they should ever be fixed, and how much time you (or realistically, they) can afford to devote to each bug.

Answer 4

Why not just pick several bands for bug severity, e.g. 1hour, 1/2 day, 1 day, 1 week and assign against them. Generally you will have a feeling for a bug -- ones for which you have no idea, put the worst case figure to it!

I wouldn't think you'd be wanted to estimate at any finer level than that, for the reasons you've quoted (taking too long to investigate, etc.)

I don't think it is a waste of time. Your customer wants to know more than the number of bugs and their priority -- they want a feeling for how much work remains.

Under no circumstances should this result in you generating more bugs. You shouldn't be hurrying against the clock to fix these. If you estimated 1 day and it tooks 10 hours, that's ok. If you estimated 1 week and it took 2 hours, good result!

This is simply an exercise in estimation!

Answer 5

Usually we will agree which bugs have to be fixed for a particular release, and then define an time frame for fixing all the bugs. For each individual bug there is a lot of uncertainty/variability in how long it could take to fix but that tends to average out with a larger number of bugs. For certain bugs that you know will take longer it may be possible to give some estimates, e.g. if you need to write a simulator or a test framework for it.

Answer 6

If these are bugs that have been found and reported, then you should be able to develop an estimate on the time to fix it (and the time to retest). The confidence of the estimate will likely be proportional to the time you spend on the estimate, perhaps explain this cost to the client.

If there are a number of related small bug reports perhaps you could collapse them into one omnibus report. This might avoid the client trying to pick and choose which bugs to fix based purely on individual estimates.

Answer 7

Don't think of this in terms of estimating how long bugs take to fix, because you can't possibly estimate that correctly.

Think of this in terms of managing client rage. If you tell them the bugs will take no time at all to fix and they end up taking 3 months, your client will be happy with you now and furious with you in the future.

If you tell them the bugs will take 3 months to fix and they actually take 3 months to fix (which they will), your client will be furious now and happy with you in the future.

I usually say bugs will take no time at all (2-3 days seems to be a good pacifying number).

Answer 8

The company I work for often gets unreasonable requests from our customers. The key thing to remember is that customers want to be well informed. We've found the best way to do this is in terms of status reports.

So, we first do a pretty good job of explaining our position. In your example, this would be something like this:

We have a set schedule for fixing the bugs in our project, which we have historically a good track record of staying on schedule. However, the process of detailing how long each bug will take to fix is quite error-prone. We'd be happy to provide you with weekly updates (or twice-weekly or daily depending on the customer) on the bugs that have been fixed and the fixes that have been tested.

However, I do believe that it is good to try to estimate how long each bug will take to fix. The reason for this is you need to understand what the total time to fix all the bugs will take. You won't be able to get an accurate estimate if you don't have an estimate for how long the individual parts will take to fix. These can be rough estimates of course (estimated no longer than spending an hour researching the problem) -- you don't want to waste too much time estimating. Then I typically factor in an extra 20%. So say the estimates for bugs are 3 days, 5 days, and 2 days. Then I'd report to the customer that we should be able to fix the bugs in 12 days. Then of course you may need to add more time for testing and re-packing your product before you can give them a deliverable.