Parkinson's Law and the Case for Small Increments

par·kin·son's law

noun — "Work expands so as to fill the time available for its completion."

— C. Northcote Parkinson, The Economist, 1955

In a previous post I wrote about Ron Jeffries, the co-founder of Extreme Programming and the man credited with inventing story points. One of Jeffries' core arguments — and the reason he eventually grew to regret story points — is that estimation tends to become a target, and once it becomes a target it stops being useful. Teams stop working toward delivering value and start working toward hitting a number.

There is a law that explains exactly why this happens. It has been around since 1955 and it has nothing to do with software. But it describes software teams perfectly.

What Is Parkinson's Law?

Cyril Northcote Parkinson was a British naval historian who published a satirical essay in The Economist in 1955. In it, he observed something that anyone who has worked in a large organization will immediately recognize: work expands to fill the time available for its completion. Give a team two weeks to do something that could be done in three days, and it will take two weeks. Give them a month, and it will take a month. The work does not shrink to fit the time — it grows.

Parkinson originally wrote about bureaucracies, not software. But the principle applies just as well to a sprint backlog as it does to a government department. When there is no urgency, work drifts. Scope creeps. Decisions get revisited. Things that are essentially done get polished indefinitely. And the team arrives at the end of the iteration with a velocity number that looks fine on paper but masks a lot of wasted motion.

Small Increments Are the Antidote

This is precisely why delivering software in small increments matters. Not because it is a methodology, and not because some framework says you should. It matters because small increments create natural constraints that work against Parkinson's Law.

When a story is sized to fit in roughly a day or two of real work, there is very little room for the work to expand. The scope is tight. The definition of done is clear. You either ship it or you do not, and you find out quickly. There is no two-week horizon during which the requirements can quietly grow, the implementation can get over-engineered, or the team can convince themselves that one more round of refinement is needed before it is ready.

Ron Jeffries made exactly this point when he described where story points really came from. The original intent was never to generate a velocity metric for a dashboard. It was to answer one simple question: how much can we get done this week? That question only makes sense if the stories are small enough to actually fit within a week. If your stories are sized in weeks rather than days, you are not doing incremental delivery — you are doing a mini-waterfall with a shorter reporting cycle.

The Danger of Long Horizons

Large projects with long timelines are particularly vulnerable to Parkinson's Law. The further out the deadline, the more time there is for the work to expand, for priorities to shift, for people to second-guess decisions that were already made. I have seen projects where the team spent more time re-estimating and re-planning than they spent writing code.

And this is not laziness or incompetence. It is human nature. When there is no immediate constraint forcing a decision, the natural tendency is to keep the options open. To add one more requirement. To wait for one more stakeholder to weigh in. Parkinson described a woman whose only task for the day was to send a postcard. Because she had the whole day, she spent an hour finding the card, another finding her glasses, ninety minutes writing it, and so on — until the day was gone. The postcard got sent. But at enormous cost relative to what the task actually required.

Software projects do the same thing at scale. The antidote is not to work faster. It is to make the units of work small enough that there is no room for the day to disappear.

What This Looks Like in Practice

In my own teams I use story points on the Fibonacci scale — 1, 2, 3, 5, 8, 13 — with 1 point representing roughly one ideal day of work. The practical effect of that convention is that stories above a certain size are a signal, not an estimate. If something is an 8 or a 13, the first question is not "how long will this take?" It is "why is this so big, and how do we break it down?"

That discipline — the habit of breaking work into genuinely small pieces before committing to it — is one of the most effective defenses against Parkinson's Law in a software team. Small stories have less surface area for scope to creep. They get done faster, which means feedback comes faster, which means the team learns faster. And when something goes wrong — and something always goes wrong — the blast radius is small.

Jeffries eventually concluded that you could skip the points entirely and just count stories, as long as the stories were all roughly the same size. That is a sensible position. But whether you use points or not, the underlying principle is the same: keep the units of work small, keep the time horizons short, and do not give the work room to expand beyond what it actually needs to be.

Parkinson observed this in 1955. Jeffries rediscovered it in the context of software in the 1990s. It is still true today.

Popular posts from this blog

The Agilish Method

Combining Agile and Waterfall methodologies into a cohesive approach, we call "Agilish" can be an effective way to deal with individuals and organizatons that struggle with the natural fuzziness of the Agile approach. Agilish offers the flexibility of Agile while accommodating the structured planning of Waterfall. This hybrid approach can help ensure that projects are adaptable while still meeting deadlines effectively. Here are a few tips to successfully implement Agilish: Start with a Clear Vision : Define the end goal and major milestones upfront, much like in Waterfall. This provides a roadmap that guides the Agile sprints. Iterative Planning : Use Agile sprints for iterative development and planning. Regularly review and adjust plans based on progress and feedback. Strong Communication : Maintain open lines of communication between Agile teams and Waterfall stakeholders to ensure alignment and manage expectations. Flexible Prioritization : Allow for dynamic prioritizatio...
Read more

Agilish — Your Get Out of Jail Free Card

Image
We do not live in a perfect world. Most of our industry has spent the better part of two decades moving toward Agile adoption, and the case for it has never been stronger. But there are still plenty of clients, managers, and organizations that are comfortable with Waterfall — and either will not or cannot change. You can make your case. You can share the evidence. And sometimes, at the end of the day, you are still doing Waterfall. This Dilbert sums up the challenge better than I can: Pick Your Battles Dale Carnegie famously argued that you cannot win an argument . Even when you are right. Even when you have the data. The moment someone feels they are being argued into a corner, they dig in — and you have lost them, regardless of the facts. The same principle applies to how we work and the methods we use. Sometimes the smartest thing you can do is let the client or the manager be right. Not because they are, but because the relationship and the work matter more than winning...
Read more

Blind Alleys and the Case for Incremental Delivery

Image
A friend recently shared a fascinating article about a mistake made by some of the greatest scientific minds of the 19th century. For decades, the best mathematicians and astronomers in the world were convinced there was an undiscovered planet — named Vulcan — orbiting between Mercury and the Sun, hidden from view. The math seemed to demand it. The calculations were elegant. The theory was accepted as fact. There was no planet. A Star-Crossed 'Scientific Fact': The Story of Vulcan, Planet That Never Was Two lines from the article stuck with me. The first: "It's easy to forget that there are people behind the data and equations. And when people are involved, there is always room for human error." The second hit even harder: "In science, you don't dwell on the blind alleys... but the blind alleys are most of what science actually does. You have to go down the blind alley, you bang your head against that blank wall at the end of it, come b...
Read more