Recently got question from my colleague how I think it make sense to estimate time you will spend on bug fixing.
My colleague point 2 common ways how to do that:

a) Rough ETA x 4

OR

b) Periodical updates of ETA

I found both make sense to use together, so I recommend something like this:

1. Initially Estimate Rough ETA x2 or x 4 (depends how you feel yourself confident with given issue), with precision to hour / day (round value up).
   Forget minutes precision in all cases, forget hour precision in many cases. If you feel that issue takes 2 minutes to fix – put estimation 0. If you feel that it’s more like 15 minutes – put estimation 1 hour. If you feel it’s like 3-4 hours, put estimation 1 day. Don’t try to be precise. Instead it should be realistic.
   For example you think it takes 20 minutes to fix issue but you don’t have previous experience with such issues, so you got 20×4 = 80 minutes and round it up to 2 hours. Put value 2 hours into issues tracking software.  If your software support ranges, put here 20 – 80 minutes range.
2. If you use estimation precision as hour, you should update your estimation at least every hour, if you see that now you can measure ETA better.  If you use precision day, update your estimation at least ones per day. As more frequently you update your estimation as better. Sure don’t be too paranoiac - update previous estimation only if it changes significantly.
   For example say you estimate issue initially to 2 hours, so after first hour you working on issue, compare your initial estimation (2 hours) with what you think you have now (don’t forget about ETA x 4), for example now you feel that you need another 35 minutes to fix, so you multiple 35 * 4 and got 140 minutes = 3 hours. So you adjust your initial estimation from 2 hours to 4 hours (1 hour you already spend plus 3 hours you think it will take more).

Advantages:

1. You update your estimations frequently so even if you made serious mistake in estimation before, you quickly resolve. Fail quickly Your colleges and boss know where you are, so excellent transparency and you agile
2. You don’t care if you need to go to made coffee, go to rest for a while etc. You made your estimation SAFE enough (x2 or x4!) and you know that in next hour (or day if bug is complex) you always may update estimation again with more precise value.

In contrast to approach above, it can better in some cases (in most of cases in my experience)  to use “relative” measurement instead of time measurement.  Unfortunately in reality, seems it’s a bit more hard to begin with in some less agile teams. Another issue is that it’s just not every issues / bug tracking software support that.  In that alternative approach you think how much more complicated given issue is, compared to other issues you have / you done before and made your estimations relative.

P.S. Many people don’t like x4. Sure it’s completely optional. I saw people (and I am one of them ) that can do exact estimations in most of cases: in some cases because of luck, in other cases because of experience. In different cases because of both. Maybe it’s because usually they (and me) do that calculation x2-x4 in the mind and do not do it formally.
Taking to attention fact that it’s impossible to work 9-12 hours per day with same focus (hope my boss don’t read that Joke), it’s best way to always remember that effectively you have about 4-5-6 hours “crazy” time per day when you really can do your job with high focus and with maximum performance, while other time is required to prepare yourself for that “fight / micro-sprint”. So at least x2 should be applied in most of cases to be safe and I recommend to do it in your mind so your colleges get only one final estimation value, not intermediate result. It’s not about transparency. It’s more about ‘useless information’ for everyone, how exactly you calculate your estimations. Everybody may value you only by how your real time to fix issue was different to what you estimate.  And in most cases if that is not important! But what is true is that nobody care how you calculate ETA after you made your job done. People trust you because of results of your work, not because you do nice calculations, but it takes you 10x times more to fix issue than you think initially.

Just keep it simple, as always