Task-Shaped Work

The unit is the task

A spec describes a destination. A task is a single step you can take, watch land, and check off before you take the next one. That difference is the whole of task-based development. You stop trying to design the entire system on paper and start moving it forward one finished piece at a time.

Call that piece the task. It is the unit of delivery: small enough to ship in days, scoped tightly enough that "done" is a fact rather than an opinion, and self-contained enough that finishing it doesn't depend on six other things landing first. A good task reads like a promise someone can keep this week. A bad one reads like a chapter of the spec graveyard, broken off and renamed.

The reason to work this way is not neatness. It is the odds. The Standish Group's CHAOS data found small projects succeed 61% of the time while "grand" projects succeed 6% (Standish CHAOS 2015). Nothing else explains the gap. The same firms staffed both kinds of project with the same engineers on the same calendars, and the only variable that moved was how much they tried to do at once. Task-shaped work is what taking that finding seriously looks like in practice. You decompose the grand project into a stream of small ones, each of which you can actually win.

What makes a task a task

Three things turn a vague request into something an engineer can ship and you can verify. Miss any one and you're back to managing a feeling instead of checking a fact.

It's scoped. A task names exactly what's in and, just as usefully, what's out. "Improve the checkout" is not a task; it's a wish. "Let a customer apply a discount code at checkout, one code per order, percentage codes only" is a task. The boundary is the point. A scoped task can be estimated, started, and finished without quietly swallowing three other pieces of work on its way.

It has a definition of done. This is the part founders underrate and the part that does the heavy lifting. The definition of done is the plain-English condition that makes "finished" checkable by someone who can't read the code. Not "the discount feature is done" but "a customer can enter a valid percentage code, the order total drops by that percentage, an invalid code shows a clear error, and no code can be used twice." You don't need to know how it was built. You need to be able to look at the running thing and say yes or no.

It ships on its own. A task that can only go out as part of a bundle isn't really a unit; it's a fragment pretending to be one. The discipline is to scope each task so it can reach production by itself, behind a flag if it has to be, without waiting on the rest of a release. That independence is what gives you the steady drumbeat instead of the quarterly big bang. It's also what keeps the failure small. When something does go wrong, it went wrong inside one task you can see, not inside a nine-month release nobody can untangle.

A task you can't verify isn't small. It's just a spec that hasn't admitted it yet.

The sample task ticket

Here is the artifact the whole method runs on. It's deliberately plain. A founder should be able to read one in under a minute and know what's being built, how they'll check it, and roughly when it lands. Reuse this format; it shows up again in the cadence and on the board.

Read down that ticket and notice what isn't there. No architecture. No database design. No instruction on how to build it. Those are the engineer's job, and putting them in the ticket is how you slide back toward the spec graveyard. What the ticket pins down is the contract: what "done" means, and how you'll know it's true. The "Why" line earns its place too. It's the thread back to a business goal, so the task doesn't become motion for its own sake.

The acceptance check is the line that protects you. Without it, "done" is whatever the person who built it says it is. With it, anyone can sit down, follow three steps, and reach the same verdict. That's the difference between reliable execution and taking someone's word for it.

Why small wins

There's an instinct, when delivery has been shaky, to scope bigger. Plan harder, specify more, get it right this time. The CHAOS numbers say that instinct is backwards. Size is the thing most correlated with failure, so the move is to make the bets smaller, not the plan thicker.

The fat tail makes the case sharper. Across large IT projects the average cost overrun is 27%, but roughly one in six becomes a "black swan" that overruns its budget by 200% and its schedule by some 70% (Flyvbjerg & Budzier). You cannot have a 200% overrun on a three-day task. There isn't room for the catastrophe to grow. By keeping the unit small you don't just improve your average outcome; you cut off the disaster that ends companies. Each task is a bet sized so that losing it costs you days, not a quarter and the runway with it.

Small units also change what you can learn. A task ships, a customer touches it, and what you find out shapes the next task instead of being buried in a spec written before anyone knew anything. The discount-code work goes live, sales discover they actually need fixed-amount codes more than percentages, and that becomes the next ticket. You couldn't have known that up front. Task-shaped work is built to absorb that the world keeps changing while you build, which is the exact thing the thousand-page spec couldn't survive.

One task, scoped and shipped, is the easy part. A stream of them, week after week, needs a rhythm, and that's what running the cadence is for.