I have always kept careful records of how long it took me to do specific jobs, not just in terms of hours but in terms of the nature and difficulty level of the job. I track my time to the nearest quarter hour, which yields an error of + or – ½ hour, and that is the optimal interval for me. I can give a pretty close estimate on a very long job.
But writing code or fixing a bug is almost impossible to estimate. A software engineer I used to work with would respond to that question (“How long is it going to take you to fix those bugs?”) by folding his hands behind his head, leaning back, and saying, “How long is it going to take you to find your car keys?”
My software rule of thumb, learned from a senior programmer-analyst in my young days, was to think of the longest time I thought it could possibly take, and then double it.
But bug fixes are an entirely different critter because you aren’t building something, you’re diagnosing and solving a problem. If you’re working with spaghetti code or if your predecessors didn’t bother to document anything, you simply can’t guess what it will take.
I did get pretty good at devising tests to home in more and more narrowly on the bug. But it’s still a crapshoot.
So—the bottom line is: they have to ask, and you have to not answer.
You should be able to predict how long it will take you to document something. Use your own history as a guide.