Subtasks Without Building a Work Breakdown Structure

The Nesting Trap

Give a team unlimited task nesting and watch what happens over six months. It starts reasonably - a big task gets split into three. Then one of those three gets split. Then someone creates an epic to hold several big tasks, and a theme to hold the epics.

Eventually the board has five levels, and a growing share of everyone's time goes into maintaining the tree: moving things between parents, closing containers whose children are done, explaining to new joiners what the difference between a theme and an initiative is. None of that ships anything.

The tell is when someone asks "where does this go?" and the answer takes more than three seconds. At that point the hierarchy has stopped being a description of the work and become a filing system with its own upkeep.

One Level, Enforced

FlowBoard allows exactly one level of subtasks. A task can have children. A child cannot have children of its own - the system prevents it rather than trusting discipline.

The enforcement is the point. "We agree not to nest too deeply" is a convention, and conventions erode the first time someone has a genuinely good reason. A hard limit means the question never comes up again, and the energy that would have gone into hierarchy maintenance goes somewhere else.

One level covers what people actually need: splitting a chunk of work into pieces that different people can pick up, or that can progress and be blocked independently. Everything beyond that is structure for structure's sake.

The Test for Whether Something Should Be a Subtask

Ask one question: would you assign this piece to someone, or track it separately?

If yes, it's a subtask. If no, it's a bullet point in the description.

Good subtasks:

• Pieces two people can work in parallel
• Work spanning several days, where partial progress is worth seeing
• A piece that might get blocked while the rest continues
• Something with a genuinely different owner - backend, frontend, copy

Not subtasks:

• A checklist of five-minute steps
• The sequential stages of one person's afternoon
• "Write tests" and "code review" appended to everything
• Anything created to make a board look busier

That third one deserves attention. Teams that add a testing subtask to every task are encoding their definition of done into the hierarchy, which doubles the item count and tells you nothing you didn't already know. Put it in the definition of done, not in the board.

Progress You Can Read Without Opening Anything

A parent shows how many of its children are done, inline in the list. Three of five, visible while scanning.

That small thing removes a surprisingly common conversation. "How's the checkout work going?" has an answer on the screen instead of requiring someone to open the task, count, and report back. It also makes stalling visible: a parent sitting at one of six for a week is a signal that no status update would have volunteered.

Parents Don't Close Themselves

Completing every subtask does not automatically complete the parent, and this is deliberate rather than a missing feature.

"All the pieces are done" and "the thing is actually finished" are different claims. The first is arithmetic. The second requires someone to look at the result and decide it works - which is exactly the check that catches the case where you decomposed the work wrongly and missed a piece.

Auto-closing parents optimises away the one moment of judgement in the whole process. The progress chip tells you the parent is ready to close; a person closes it.

What to Do Instead of Deeper Nesting

If you find yourself wanting a third level, one of these is what you actually want:

• A release. Grouping a body of work that ships together is what releases are for. That's your epic.
• A tag. Cross-cutting concerns - a client, a quarter, a theme - are tags. They group without nesting and a task can carry several.
• A separate flow. If a "parent" holds twenty children and has its own backlog, it isn't a task. It's a project.
• Fewer tasks. Sometimes the honest answer is that you're decomposing work that didn't need decomposing.

Subtasks also carry their own priority scores and appear in the flow like any other task, so a subtask that matters gets worked when it matters rather than waiting for its parent's turn.

And Don't Date the Children

A recurring mistake: giving every subtask a due date worked backwards from the parent's deadline. That's five internal dates you can be technically late on, none of which anyone outside the team is tracking, all of which contribute to an overdue list that stops meaning anything.

Date the parent - the thing that represents a real commitment - and leave the children to priority. See deadlines in a continuous flow.

Summary

The value of task hierarchy is almost entirely captured at the first level. Everything after that is maintenance cost disguised as organisation. One level, enforced, with a visible progress count and a human deciding when the parent is genuinely done, is enough for real work and too little to build a bureaucracy in.

Get started with FlowBoard, or read about breaking down work into tasks.

Frequently Asked Questions

Why does FlowBoard only allow one level of subtasks?

Because deeper hierarchies cost more to maintain than they return. One level covers splitting work between people or tracking pieces that can be blocked independently; beyond that, teams spend time managing the tree rather than the work.

What should be a subtask and what shouldn't?

If you'd assign the piece to someone or track it separately, make it a subtask. If it's a step in one person's afternoon, put it in the description as a checklist item.

Does completing all subtasks close the parent?

No, and that's intentional. "All pieces done" and "the thing is finished" are different claims - the second needs a person to confirm. The progress indicator tells you it's ready; you close it.

What do I use instead of epics?

Releases for work that ships together, tags for cross-cutting themes, and separate flows for anything with its own backlog. Each groups work without creating a hierarchy to maintain.

Do subtasks have their own priority?

Yes. They're full tasks with their own scores, assignees and statuses, and they appear in the flow accordingly rather than being hidden until the parent comes up.