Should you schedule every hour?

Updated 2026-09-12

The short answer

No, and the reason is not about temperament. A system run near full utilisation has no capacity to absorb variation, and waiting times rise steeply as utilisation approaches its limit.

Plan roughly half of your available hours. The rest is not slack in the pejorative sense — it is the capacity that lets a day absorb the thing that always happens without the whole schedule collapsing.

Why the last hours are the expensive ones

Queueing systems share a well-known property: as utilisation rises towards 100%, waiting time does not rise smoothly — it rises sharply, because there is no longer any idle capacity to absorb a burst. A motorway at 60% occupancy flows; at 95% it stops, and the extra 35% of cars did not reduce throughput by 35%.

A day booked to 100% behaves the same way. One task overrunning by twenty minutes has nowhere to go, so it displaces the next thing, which displaces the next. By mid-afternoon the schedule describes a day that did not happen, and the plan becomes something you are working against rather than with.

This is not an argument for planning less work. It is an argument for planning fewer hours, because a plan that assumes no variation is a plan that assumes something untrue about every working day.

What to schedule, and what not to

Schedule the things that need a specific time: meetings, anything with a hard external dependency, the one block of focused work you are protecting.

Do not schedule the rest into named hours. Keep it as an ordered list. The order is the decision; the hour is a guess, and the hour is what will be wrong first.

This is the distinction that makes time-blocking survive contact with a real week: commit to the sequence, not the timetable. A sequence degrades gracefully when something overruns — everything just happens later. A timetable does not; it breaks, and a broken timetable gets abandoned.

What the unbooked time is actually for

It is not spare. It has jobs, and naming them stops it being the first thing surrendered:

• Overrun. Your estimates are wrong in the same direction as everyone's. That is what an estimate is for — not accuracy, but visibility.
• The thing that arrives. Something always does. In a day with no room every arrival is a crisis; in a day with room it is just work.
• The reload after a switch. Coming back to something costs real time that never appears as a task.
• Finishing. The last twenty percent of anything takes longer than it looks, and it is what a fully booked day systematically has no room for — which is why such days produce many started things and few finished ones.

How much is right

Half your available hours is a good starting figure, and be honest about the denominator: a working day does not contain eight usable hours once meetings and their fragmented edges are removed.

Then correct it with evidence rather than feel. Compare planned against actual for two weeks. If you consistently finish with time left, plan more. If you consistently run over, plan less. That comparison is the only real answer, and it is specific to your work rather than to anybody's rule.

One thing to hold regardless: cutting the buffer is the first response to a busy week and the one that makes it worse. A week with no room is exactly the week most likely to produce something unexpected.

Where to go next

• How long should a task take? — what an estimate is for, and why accuracy is not the point
• Little's Law, applied to a working day — the queueing result behind all of this
• How to prioritise your tasks — the three conditions

Using this in Decide One

Decide One asks for a duration on each line and shows the total, so a day that does not fit says so before it starts rather than at six o'clock. It does not ask you to timetable the day — the order is the commitment.

A line you did not finish is unfinished. It is not marked against you, and a day you did not open is not counted.

Open Decide One — free to use, with no account. Nothing you write leaves your device.