So if you have planned meeting in a week, group them (but not all of them on a single day either) and mark that day as unavailable. That usually already reduces a week of work to 4 days.
Then it's usually more on the longer term, but you (well, each dev actually) may benchmark continuously previous estimates against reality, so that they can understand their bias over time.
2/ do delegate approvals with a few basic rules: have a (short) rationale written down for each decision taken without a n+1 request; should be reversible if it's important.
3/ how long are your sprints usually?
Estimation in engineering is famously hard to solve. Maybe the best answer is - don't.
And yes, if devs are off for a few days, do some arithmetic to shrink the expected velocity by whatever ratio of time you have missing people.
Short version: Track the predictions and the actual time to solve the task, and then use that data to adjust the new predictions to a realistic ones.
I didn’t say “developers routinely mis-estimate their projections by ~25% because they do not anticipate admin overhead sich as emails, phone calls, or other non technical back and fourth.” So if projections are regularly skewed hedge the projections and refine the process.
Anyway, the advantages of the Joel's method are:
1) he writes better than you and me
2) it's automatic, so there are not hard feelings or overoptimistic managers
Tell them you’re “hedging.”
Get the feel for that and reappraise.