Task Breakdown People Can Follow: Splitting Work Down to a Day

The card says redesign onboarding. It has an owner, it has a due date at the end of the month, and it has been in the same column for three weeks. In every standup the answer is that it is in progress, which is true and also useless. Nobody is avoiding it. The owner has done real work on it. There is simply no point at which anything can be called finished, so there is nothing to report and nothing anyone else can pick up.

That card is the standard symptom of a missing task breakdown. The fix is not a better tool or a firmer deadline. It is splitting the work until each piece can be finished by one person in roughly a day, with a condition that makes finished unambiguous. Doing that well is a skill, and most of the difficulty lies in choosing what to split along rather than in the splitting itself.

Why a task that never moves was never split

Large tasks fail in three specific ways, and each is worth recognising because the fix differs.

Progress becomes invisible. A three week task has no internal milestones, so between the first day and the last there is no honest signal. The owner cannot tell whether the work is on track, and neither can anyone else. Problems surface at the deadline, which is the latest and most expensive moment to find them.

Nobody can help. Work that exists as one undivided lump can only be done by the person holding it. A second person cannot be added without a long handover conversation. A breakdown is what makes help possible, which matters most exactly when the work is late.

Starting is harder than it should be. A vague large task offers no obvious first move, so it loses to every small dated thing in the same list. This is the mechanism behind most procrastination on important work, and it is why tools that split a task into steps are popular with people who have no interest in project management at all. The relief comes from having a first action that is small enough to begin without deciding anything.

The common thread is that estimation, help and momentum all depend on the same thing: a piece of work small enough to have a visible end.

How small is small enough

The practical answer, for team work tracked on a board, is one piece of work that one person can finish within about a day. A range of half a day to two days covers almost everything. The reasoning is not arbitrary.

At a day or less, a card that has not moved in two days is visibly stuck rather than possibly fine. At more than two days, the standup cannot distinguish progress from drift. Below about two hours, the overhead of writing, assigning and tracking the card exceeds the value of tracking it, which is where checklists inside a card belong instead.

Two qualifications matter. Work that is genuinely uncertain cannot be sized at all until someone has looked at it, and the correct split there is a timeboxed investigation with a written outcome rather than a guess dressed as a task. And a breakdown only needs to be this fine for work starting soon. Splitting next quarter's work to the day is effort spent on a plan that will change before anyone reads it.

Three ways to split, and when each is right

Most bad breakdowns come from splitting along the wrong axis rather than from splitting too little.

Axis	The split looks like	Best when	Risk
By outcome	Each piece delivers something usable on its own	Almost always, especially with unclear scope	Harder to write, needs thinking about value
By component	Each piece is one part of the machine	The parts are genuinely independent	Nothing is usable until the last piece lands
By stage	Design, then build, then test, then document	Work with a mandated process or handover	Progress is invisible until the final stage

Splitting by outcome is the one to reach for first. A redesign of onboarding split by outcome produces the new sign up form, then the welcome email, then the first run tour, each of which can be shipped and judged alone. Split by stage, the same work produces designs for everything, then code for everything, then testing for everything, and nothing is verifiable until the end. The stage split feels more orderly and hides risk until the last week.

Two axes to avoid. Splitting by person creates pieces that exist only because of who is free, and they stop making sense when someone is reassigned. Splitting by amount of effort, into five equal pieces because the estimate was five days, produces tasks with no meaning at all, and it is surprisingly common in plans written to satisfy a template.

A worked example

Redesign onboarding, split by outcome, with a condition of done written for each.

Replace the sign up form, done when a new account can be created through the new form on staging. Write the welcome email, done when the text is approved and the template renders in the main mail clients. Add the first run checklist to the empty dashboard, done when it appears for a new account and dismisses permanently. Instrument the funnel, done when sign up to first action is visible in the existing reporting. Remove the old form, done when no route reaches it.

Five pieces, each roughly a day, each shippable alone, each judged by someone who was not in the room. Compare this to the same work split by stage, where the first three cards would be research, wireframes and review, none of which can be verified by anyone outside the project and all of which can absorb unlimited time.

The wording carries most of the weight. A task that starts with a verb and names its object can be judged finished, and a task written as a topic cannot. Onboarding flow is a topic. Replace the sign up form is a task.

Cards or a checklist inside a card

This is the decision that most often produces either a cluttered board or a board that hides work, and it has a clean rule.

Use	When	Why
Separate cards	The pieces have different owners, different dates, or move at different speeds	Each needs its own place in the flow
A checklist in one card	The steps belong to one person, in one stretch, in a fixed order	The board stays readable and progress still shows

A deployment with eleven mechanical steps is one card with eleven checklist items. A feature with five outcomes owned by three people is five cards. When in doubt, ask whether two of the pieces could be in different columns at the same time. If they could, they are cards.

Checklists are also the right home for the small work that clutters a board: the notify support step, the update the changelog step. They still need to be visible, and a card that shows how far along its checklist is from the board view gives that without adding rows. Whether a tool shows subtask progress on the card face, rather than only inside it, is worth checking against how a team actually reads its board and card fields.

Estimating comes out of the breakdown

The usual order is backwards. Teams estimate a large task, then split it to fit the estimate, which guarantees that the pieces are arbitrary. Splitting first and adding up afterwards produces a number that can be defended, because each line can be questioned individually.

It also exposes the real problem with estimates, which is rarely the arithmetic. When a breakdown is read aloud, somebody usually says that one of the five pieces depends on a decision that has not been made, or on a person who is not available that week. That sentence is worth more than any estimating technique, and it only gets said when the work is in pieces small enough to see.

Three checks on a finished breakdown are worth the two minutes they take. Does any piece depend on a piece that comes later, which means the order is wrong. Is any piece owned by a team rather than a person, which means it has no owner. Does any piece lack a condition of done that someone outside the work could verify, which means it will be reported as in progress for as long as it exists.

Where breakdowns go wrong

Splitting far off work in detail. A task breakdown has a shelf life. Next month's work split to the day will be rewritten before it starts, and the rewriting is what makes teams distrust planning. Split the next two weeks finely and leave the rest coarse.

Hiding uncertainty in a normal looking task. When nobody knows how long something will take, an estimate is a wish. A timeboxed investigation with a written result, one day and an answer on a card, converts unknown work into a decision. The point of the timebox is that it ends whether or not the answer is complete.

Letting the pieces lose their parent. Five cards with no visible connection to the thing they belong to produce a board where nobody can tell what is nearly finished. A label, a shared prefix, or a parent card that links to the pieces is enough. Losing the link is how a breakdown becomes a pile.

Splitting until the pieces have no meaning. Twenty cards of thirty minutes each are administration, not planning. If two adjacent pieces would always be done by the same person in the same sitting, they are one piece with a checklist.

A last practical note on getting a first draft of a split. Producing an initial list of pieces from a description is something a language model does adequately, and teams increasingly use one to get a rough list before editing it down. The draft is a starting point rather than an answer, because the model does not know who is available, what was decided last week, or which piece is the risky one. Where that matters is in how the list gets into the board without being retyped, which some tools support through an assistant connection and others do not.

What to change first

Take the oldest card on the board that has not moved in a week and split it by outcome, not by stage, into pieces of about a day, each written as a verb plus an object with a condition that says when it is done. Do it in front of the person who owns it, since half of what emerges is information nobody had written down. If the pieces need to stay connected to the thing they came from while still moving separately, Pinateca is free for up to five people and ten boards.

Q1. How small should a task be broken down?

For team work tracked on a board, small enough that one person can finish it in about a day, with half a day to two days covering most cases. At that size, a card that has not moved in two days is visibly stuck. Below roughly two hours the tracking costs more than it returns, and those steps belong in a checklist inside a card instead.

Q2. Should tasks be split by stage, such as design then build then test?

Only when a process requires it. Splitting by stage makes progress invisible until the last stage, because nothing is usable until everything has passed through every step. Splitting by outcome, so that each piece delivers something that can be shipped and judged on its own, surfaces problems earlier and lets other people help.

Q3. When is a checklist better than separate cards?

When the steps belong to one person, in one stretch of work, in a fixed order. A release with eleven mechanical steps is one card with eleven checklist items, while a feature with five outcomes owned by three people is five cards. The test is whether two of the pieces could sit in different columns at the same time.

Q4. What should be done with work that cannot be estimated?

Convert it into a timeboxed investigation with a written result: one day, and an answer recorded on the card. The timebox ends whether or not the answer is complete, which is what stops open ended research absorbing a week. Estimating the real work afterwards is then based on something known rather than on a guess.

Q5. How far ahead is it worth breaking work down?

Roughly the next two weeks in detail, and everything beyond that coarsely. Fine grained plans for work that starts next quarter get rewritten before anyone follows them, and repeated rewriting is what teaches a team to ignore plans. Keep distant work as large items and split each one shortly before it starts.