Slightly tangential, but important note for management. Every piece of work can be either proactive or reactive. Proactive stuff is planned and possibly scheduled. Reactive stuff is, well, reaction to client call. Note that client call can spawn another reactive task to fix something. If client issue can be converted to proactive task - good, you can put it to backlog and plan. Reactive tasks naturally have higher priority than any proactive task (either contractual SLA, policy to always pick up phone, etc.).
Proactive tasks have interesting impact on hour consumption. Lets say client call takes 1 hour to complete. Unless client calls are uniformly distributed over the day, there is nontrivial probability of calls to happening with intervals lower than 1 hour. In order to complete each proactive task 1,5 hour after the call was placed with decent probability, operator can accept something like 3 calls a day (~40-50% load on reactive operator is considered critically high, higher loads inevitably lead to periods with significantly higher reactive load than operator can handle). That is 3-4 hours of work in an 8 hour day. If reactive workloads are intermixed with proactive loads, interruptions caused by reactive tasks significantly prolong time taken to complete proactive tasks.
> there were days where I would plan to do about 5 or 6 bug fixes, but I would get a slew of phone calls <...> and would have to move other plans.
Evidence based scheduling [1] is a good strategy to avoid moving plans. Even if you do not have fixed phone support hours, you can still try to average hours spent on phone support. If your average week involves 20 hours of phone support, then planning for anything more than 15 hours of proactive work is too optimistic, considering 40 hour week. Once you mix proactive and reactive tasks, your planning periods must be longer - roughly periods where reactive loads average smoothly, probably nothing shorter than a week.
Proactive tasks have interesting impact on hour consumption. Lets say client call takes 1 hour to complete. Unless client calls are uniformly distributed over the day, there is nontrivial probability of calls to happening with intervals lower than 1 hour. In order to complete each proactive task 1,5 hour after the call was placed with decent probability, operator can accept something like 3 calls a day (~40-50% load on reactive operator is considered critically high, higher loads inevitably lead to periods with significantly higher reactive load than operator can handle). That is 3-4 hours of work in an 8 hour day. If reactive workloads are intermixed with proactive loads, interruptions caused by reactive tasks significantly prolong time taken to complete proactive tasks.
> there were days where I would plan to do about 5 or 6 bug fixes, but I would get a slew of phone calls <...> and would have to move other plans.
Evidence based scheduling [1] is a good strategy to avoid moving plans. Even if you do not have fixed phone support hours, you can still try to average hours spent on phone support. If your average week involves 20 hours of phone support, then planning for anything more than 15 hours of proactive work is too optimistic, considering 40 hour week. Once you mix proactive and reactive tasks, your planning periods must be longer - roughly periods where reactive loads average smoothly, probably nothing shorter than a week.
[1]: https://www.joelonsoftware.com/2007/10/26/evidence-based-sch...