Parkinson's Law

A generous schedule looks like it produces slack. Give four weeks to something that needs two and, on paper, two weeks come back for something else. On the ground it doesn't work out that way: four weeks produces four weeks of work.

Pagedeck saw the gap plainly. Mia allowed three weeks for document export. In week one Theo built the basic behaviour; in week two he added two more formats. Week three went into adjusting spacing and button placement on the export screen, plus two configuration options nobody had asked for. The feature shipped exactly three weeks later. Another team that had to handle the same feature under pressure shipped in six days, and the parts users actually touched were no different between the two.

The observation carries a name because it came out of a long study of administrative organisations. The point isn't that people are lazy. It's that when time is available, work appears to fill it — and the work that appears is usually work nobody needed, produced by people acting entirely reasonably.

Tasks expand toward the remaining time along three paths.

1. The standard of "done" rises. With a distant deadline you keep re-asking whether the current state is good enough, and each asking reveals something worth polishing. Week three's spacing revisions are this path, and a standard raised that way becomes the baseline expectation for the next feature — which is how one generous schedule makes the following three look slow.
2. Unrequested work arrives. Time is available, so things that would be nice get added. Scope grown this direction skipped any agreement, which overlaps with scope creep; the difference is that nobody outside asked for it, the team grew it themselves, which also means nobody outside knows it happened.
3. The start slides. With a deadline three weeks out, week one goes to gathering references and comparing approaches. Sometimes that comparison changes the outcome. Usually it selects on day eight the approach that would have been selected on day one, with a document explaining the choice that nobody reads again.
4. Together they turn the schedule from an estimate into a target. Three weeks began as a prediction that it would take three weeks, and became a decision to spend three weeks.

The way to use the law in reverse is to fix the time first: decide this gets three days, and make the decision on day three using whatever exists. What gets fixed is the time, though, not the scope of the output. What comes out in three days is what those three days determine, and that has to be acceptable in advance. Fix time and scope together and you get deadline pressure, where the thing that shrinks isn't scope but quality.

Fixing the time requires fixing a definition of done alongside it. Without one line written in advance about what has to exist on day three, day three arrives in a state that feels like it just needs a little more.

It comes up when schedules get set, and again when a delay gets reviewed. Four places most often.

1. Estimation meetings. The law appears as the argument against padding. There's a counter-argument, though: remove all slack and the first surprise takes it out of quality. The usual compromise is to pool the slack at the level of the cycle rather than per task, where it stays visible and can be spent on whatever actually goes wrong.
2. Fixed-length cycles. Holding a sprint at two weeks is itself built on this law. The amount committed gets sized to the cycle, so there's no room for work to expand indefinitely, and anything that doesn't fit becomes a visible decision rather than a quiet extension.
3. Meetings. An hour-long meeting takes an hour. Booked for 30 minutes, the same decision frequently arrives in 30 minutes, and when it doesn't, that reveals the topic genuinely needed more time. Two lines of agenda in the invitation separate those two cases before anyone sits down, and a recurring hour with no agenda is the clearest example of this law anyone has on their calendar.
4. Retrospectives. The law gets raised when nothing was late and the output is still thin. Three weeks spent producing what six days would have produced is a question about where the other two weeks went, and it's a more useful question than asking why anything was late.

"Give it three weeks and it'll take three weeks. Let's cut it to ten days."

Fixing a shorter time to stop the expansion.

"Slack goes at the cycle level, not on each task."

Keeping the buffer from being consumed inside individual tasks.

"Let's decide on day three with whatever we have then."

Time is the constant and scope is the result, agreed to before the work starts.

What Mia changed after the export feature was the habit of writing the definition of done first. From the next feature onward, three lines went down before work started: support two formats, process a 300-page document within 40 seconds, tell the user when it fails. The same team shipped a comparably sized feature in ten days, and the kind of work that filled week three simply didn't appear on the board. Spacing adjustments didn't become forbidden — once there was a line marking "finished," they moved to the candidate list for the next cycle.

The most common reading is that this says people are lazy. Filling the available time sounds like wasting it. But revising the spacing in week three was diligence, not laziness. Looking for improvements with time in hand is a good instinct; the problem is having the time to look. Use this law as a judgement about people and the team starts hiding the fact that time was left over, which removes the information you needed for planning and leaves every future estimate slightly padded.

The other reading is that schedules should simply always be short. Cut four weeks to two and it finishes in two. In reality, shortening the time shortens either scope or quality. Agreeing to cut scope alongside it is using the law; leaving scope intact and cutting only time means testing and review go first, quietly and without a decision. A decision to compress to ten days is meaningful only when it's written down together with what was dropped.