When to split a task into subtasks (and when not to)

Every schedule eventually contains a bar that nobody can read: “Build the website”, 30 working days, 60% complete. Is it on track? Nobody knows, because the bar hides several pieces of work with different owners, different finish dates and different risks. Splitting it into subtasks turns one opaque estimate into several small ones that can be planned, assigned and checked.

Splitting is not free, though. Every new row has to be estimated, linked and updated, and a plan with three hundred tiny tasks is as unreadable as a plan with ten giant ones. This guide explains how to decide, with concrete signals, a method and an example.

What a subtask is, and what it is not#

A subtask is a task nested under another one, the parent or summary task. In a scheduling tool the parent stops having a duration of its own: its start is the earliest start of its children and its finish is the latest finish. The parent becomes a container, and the real planning happens one level down.

That is the same logic as the work breakdown structure (WBS), a term that belongs to the standard project management vocabulary^[1]: the project is divided into deliverables, the deliverables into work packages, and so on until each element is small enough to plan. A subtask is simply one more level of that breakdown.

A subtask is not:

• a reminder (“call the printer”), which belongs in a comment or a to-do list;
• a step inside one person’s routine (“open the file, apply the template, export”);
• a way to give credit to everyone who helped.

Five signals that a task should be split#

The fourth signal is the one most often missed. If testing can start when the first module is ready, but the plan links testing to the end of “Develop all modules”, the schedule is longer than reality. Splitting lets you link the successor to the piece it really waits for.

The fifth signal is a rule of thumb rather than a law. Some planners use an “8/80” heuristic (no task shorter than a working day or longer than two working weeks); others size tasks to the reporting cycle. The underlying idea is the same: a task should finish often enough for its status to be a fact rather than an opinion.

When not to split#

Splitting is the wrong tool in three situations.

One deliverable, several contributors. A contract proposal, a design review or a board presentation cannot be half done in a meaningful way. Splitting it into “write section 2” and “write section 3” creates rows that nobody updates, while the real question (who is accountable for the whole proposal?) stays unanswered. Keep one task, assign one accountable owner and add the other people as assignees or in comments.

Steps that only matter to one person. If the only person who cares about the steps is the one doing them, a checklist in the task notes is enough. The schedule should describe coordination, not personal method.

Work you cannot estimate yet. Splitting an unknown into five unknowns does not reduce uncertainty. Plan a short discovery task first, then split once you know what the pieces are.

How to split a task, step by step#

1. Name the outcomes, not the activities. “Product pages approved” is a better subtask than “work on product pages”, because it has a clear finish.
2. Check the 100% rule. The subtasks together must cover all the work of the parent, and nothing outside it. If something is missing, it will turn up later as an unplanned delay.
3. Give each subtask one owner and an estimate in working days.
4. Link the subtasks to each other and to the rest of the plan, choosing the right dependency type: not everything is finish-to-start. The guide to task dependencies and lag covers the four types.
5. Move the links from the parent to the children. A successor should depend on the specific subtask it waits for, not on the whole summary task.
6. Let the dates recalculate and compare the new finish with the old single estimate.

Before saving the breakdown, run this checklist:

• Can each subtask be marked complete without discussing the others?
• Does each subtask have a single owner and a duration?
• Is each one short enough to finish within one or two reporting periods?
• Do the subtasks add up to the whole parent, with nothing missing and nothing extra?
• Is every subtask linked to a predecessor or a successor, or deliberately free?
• Would anyone outside the team understand the subtask names?

Worked example: splitting a 20-day task#

A web team has one task in its plan: “Build product pages”, 20 working days, assigned to the lead developer. Broken down by outcome, it becomes:

The calculation, in working days: design runs on days 1–5, and the copy on days 1–6 because it starts together with the design. Templates are built on days 6–13. Content loading waits for both the build (finished on day 13) and the copy (finished on day 6), so it runs on days 14–16. Review closes on days 17–18.

Three things happen that the single bar could not show:

• The parent now lasts 18 days, not 20, because the copy runs in parallel with design and build.
• The copy has 7 days of slack: it finishes on day 6 but is not needed until day 13. A copywriter who is late by a week does not delay anything.
• The real chain is design, build, loading, review. A two-day delay on the build moves the finish of the parent by two days, because the build has no slack.

Progress also becomes honest. On day 10, “Build product pages: 50%” used to be a guess. Now it reads: design done, copy done, build on its fifth day out of eight, loading and review not started.

Common mistakes#

• Splitting by person instead of by outcome. “Anna’s part” and “Marco’s part” say nothing about what will be delivered.
• Leaving the links on the parent. The subtasks look tidy, but successors still wait for the whole summary task.
• Going too deep. Subtasks of half a day that nobody updates make the plan look precise while it drifts.
• Summary tasks with their own estimate. If the parent keeps a manual duration that disagrees with its children, the plan has two truths.
• Splitting late. Breaking a task down when it is already behind helps, but the slack you could have used has often been spent.

Once tasks are the right size, the next step is estimating them well: the guide on how to estimate task durations explains three-point estimates and how to avoid optimism.

How to do it in Planitude#

In the Gantt chart and List views, select a task and press Tab to indent it under the row above, or Shift+Tab to move it back up: subtasks can go as many levels deep as you need, as in Microsoft Project. The summary task takes its start and finish from its children automatically, and its colour flows to the whole branch, so phases stay readable.

Links can be of all four types (FS, SS, FF and SF), with lead and lag in working days, and you can turn on the critical path to see which subtasks have no slack. Several people can be assigned to the same task, and the Workload view shows whether the new breakdown overloads anyone.

When you type the name of a new subtask, the AI assistant suggests a duration, an assignee and a predecessor, which you accept with Tab. You can also ask it to propose a breakdown of a phase: every change is shown as a preview before it is applied. Plans imported from an .mpp file keep their hierarchy, so you can refine an existing breakdown instead of rebuilding it.

Frequently asked questions#