Subtasks Done Right: Why One Level of Nesting Is All You Need

You opened a task to "Add billing," and three weeks later you're staring at a six-level tree — epic, story, task, subtask, sub-subtask, and a lonely checklist item buried at the bottom — and you genuinely cannot tell which parts are done. The work didn't get more complex. Your structure did. And somewhere in the maintenance of that structure, the actual shipping stopped.

This is the quiet failure mode of solo devs and tiny teams who adopt "real" project management. You start with a clean board. Then you add nesting because one task felt too big. Then you nest the nesting. By the time the tree is four levels deep, you spend more energy grooming the hierarchy than writing code. The fix isn't more structure. It's a hard cap: one level of subtasks, no more.

---

The deep-hierarchy trap

The dream of deep nesting is total fidelity: every piece of work captured in its exact place in a perfect tree. Epics contain stories, stories contain tasks, tasks contain subtasks, and you can drill down forever until you hit something atomic. It feels rigorous. It feels like the thing serious teams do.

It's the Work Breakdown Structure reborn — the same waterfall-era bureaucracy that small teams fled when they switched to a Kanban board and a couple of columns. The WBS made sense when you had a project manager whose entire job was maintaining the tree. You don't have that person. You are that person, and you also have to do all the work the tree describes.

Here's what actually happens when nesting goes deep:

• You maintain the tree instead of doing the work. Every reorganization, every "should this be a subtask of that story or its own story" decision is pure overhead. It produces zero shipped features.
• Status becomes ambiguous. A parent is "in progress." Two of its five children are done, one is blocked, two haven't started. What's the real status? Nobody knows without expanding everything.
• Work hides four levels down. The thing you actually need to do today is collapsed inside a node inside a node. Out of sight, it rots. This is backlog decay happening inside individual tasks.
• Estimation gets fuzzy at every level. You roll up children to estimate parents, but the rollups compound error. (More on why that's a losing game in story points are estimation theater.)

---

Why exactly one level is the sweet spot

A single level of subtasks is the most useful structure that doesn't turn into bureaucracy. The model is dead simple: a parent task plus a flat checklist of subtasks under it. That's it. No grandchildren.

This maps cleanly to how your brain already chunks work. A task is one meaningful unit — "Add Stripe billing." It's slightly too big to hold in your head as a single atom, so you crack it into a checklist: connect the API, build the pricing page, handle webhooks, add the success state, test the failure path. Five subtasks. A flat list. You can see all of them at once.

The cognitive case is straightforward. A flat checklist has one level of indentation, so you can scan it in a single glance and know exactly what's left. The moment you add a second level, you've created a structure that no longer fits in working memory — you have to expand and collapse nodes to reason about it, and every expand/collapse is a context switch. Gloria Mark's research on attention puts the cost of a full context switch at roughly 23 minutes to fully refocus; you don't pay the whole bill for a UI toggle, but you pay a real slice of it every time you navigate a tree instead of reading a list.

One level also keeps status honest. A parent with a flat checklist has an unambiguous progress signal: three of five done. You don't have to interpret a partially-expanded tree. The checklist is the status. This is the same clarity argument behind keeping subtasks shallow — depth buys you nothing but confusion.

---

How to break a task into subtasks

The test that does the heavy lifting is step four. If a subtask needs its own subtasks, it was never a subtask — it's a task wearing a disguise. Promote it. This single rule prevents the tree from ever growing past one level, because depth can only happen when you let a child sprout children. Forbid that, and the structure stays flat by construction.

---

Subtask vs sibling task vs new project

The hierarchy debate usually disappears once you have a clear rule for which container a piece of work belongs in. Here's the decision, top to bottom:

The trap is using nesting to express all three relationships. People reach for subtasks-of-subtasks when they really mean "sibling task," and they reach for epics when they really mean "new project." Both substitutions create depth you don't need.

Notice what's missing from that table: the epic. For a small team, the epic is the layer to avoid. It exists to roll up many stories for reporting to people who aren't doing the work — stakeholders, portfolio managers, a PMO. You don't have those. When you feel the pull toward an epic, you almost always want a project (a separate board) or a label (a flat tag you can filter by). Either gives you grouping without inventing a hierarchy level you'll spend your evenings grooming.

---

Deep nesting vs one level: the honest tradeoff

I'm not going to pretend one level can express everything. Deep hierarchies genuinely do capture more relational nuance. The question is whether that nuance pays for itself on a two-to-ten-person team. It doesn't.

The cons of one level are mostly the cons of doing less, which is the entire point. The cons of deep nesting are the cons of doing more accounting — and accounting is not the job. This is the same principle behind why feature bloat kills developer productivity: every extra layer of capability has a carrying cost, and most of the time the cost dwarfs the benefit.

---

How this connects to estimation and WIP

One-level nesting isn't an isolated UI rule. It's load-bearing for two other habits that keep a small team fast.

Sizing: a "Large" task is one you must split

If you do any sizing at all, the most useful output isn't a number — it's a signal. When a task reads as "Large," the correct response is not to assign it more story points and schedule it across a sprint. It's to split it into subtasks (if it's one deliverable) or into sibling tasks (if it's several). "Large" means "I can't see the whole thing yet." Breaking it into a flat checklist is how you make it visible. The one-level cap forces this: you can't bury the bigness in a tree, so you have to confront it and split.

This is why I'm allergic to estimation rituals that exist to predict big tasks rather than break them. If your estimate is bigger than a day, the estimate has done its only useful job — it told you to split. The number after that is theater, which I get into in forget velocity, track cycle time and story points are estimation theater.

Work-in-progress: count parents, not leaves

A flat checklist also keeps your work-in-progress count meaningful. When you limit WIP, you're limiting the number of things in flight. With deep nesting, "how many things am I working on" becomes unanswerable — is it one epic, three stories, or eleven leaf nodes? With one level, the unit is obvious: a parent task is one unit of WIP, full stop. Its subtasks are just the checklist for finishing that one unit.

This keeps the shipping faster with WIP limits discipline intact. You pull a parent task, you finish its whole checklist, you ship it, you pull the next one. No partially-done parents with abandoned subtrees clogging your board.

---

How GritShip caps subtasks on purpose

This is one of the few places where I'll point at the product, because the design decision is the argument. GritShip supports exactly one level of subtasks. You can break a task into a flat checklist of subtasks. You cannot give a subtask its own subtasks. That's not a feature we haven't built yet — it's a wall we put up deliberately.

The reasoning is the whole post: a small team's project management without bloat depends on never inventing structure that costs more to maintain than it returns. By making deeper nesting impossible, the tool removes the temptation entirely. You never have the "should I nest this further" debate, because the answer is decided for you. When something wants to be deeper, the only move is the correct one: promote it to a sibling task, or spin up a new project.

No epics, either. We don't have an epic layer because a small team doesn't have the stakeholders an epic serves. Grouping happens through projects (separate boards) and labels (flat, filterable tags) — both flat, both cheap, neither a hierarchy you babysit. The result is that the structure stays legible at a glance, every interaction stays under 200ms, and you spend your time on the work instead of on the org chart of your work.

If you want the broader philosophy, the post on PM tools built for teams of 50 covers why enterprise hierarchy assumptions actively harm tiny teams. And if your tasks tend to be cryptic regardless of nesting, write tasks for your future self pairs well with this — a clear flat checklist beats a deep tree of vague nodes every time.

---

A quick before-and-after

Here's the same work, modeled both ways. Deep nesting:

• Epic: Billing
  • Story: Subscriptions
    • Task: Stripe integration
      • Subtask: API keys
        • Sub-subtask: rotate keys in prod

You cannot tell what's done. You navigate four levels to find one checkbox. The "epic" exists for nobody.

One level:

• Task: Add Stripe billing (P2)
  • Connect Stripe API and store keys
  • Build pricing/checkout page
  • Handle webhooks (success + failure)
  • Add success and error states
  • Test the declined-card path

Three of five done means three of five done. The whole thing fits on one screen. When "Build pricing/checkout page" turns out to be its own beast, you promote it to a sibling task — "Pricing page" with its own flat checklist — and billing stays clean. That's the entire system.

---

Frequently asked questions

Isn't one level of subtasks too limiting for complex projects?

Complexity is real, but you express it with more tasks and more projects, not more depth. A complex project is many flat-checklist tasks on a board, plus separate boards for separate streams of work. Depth doesn't add capability — it adds maintenance. If something genuinely needs nesting beyond one level, it's a sign the parent should be split into siblings or promoted to its own project.

When should I use a subtask instead of a separate task?

Use a subtask when the item is meaningless on its own and only exists as a step toward finishing the parent — a checklist item, like 'write tests' under 'ship the export feature.' Use a separate (sibling) task when the work ships independently and deserves its own status and priority. The fast test: if it has its own definition of done that matters to a user, it's a task, not a subtask.

What about epics? My old tool used them constantly.

Epics roll up many stories for reporting to stakeholders who aren't doing the work. Small teams don't have those stakeholders. When you reach for an epic, you almost always want either a project (a separate board) or a label (a flat, filterable tag). Both give you grouping without adding a hierarchy level you'll spend time grooming.

How do I know when a task is too big and needs subtasks?

Two signals. First, you can't finish it in roughly a day. Second, you can't picture the concrete first action. Either one means break it into a flat checklist of subtasks. If sizing tells you a task is 'Large,' that's not a number to schedule around — it's an instruction to split.

What happens when a subtask turns out to need its own subtasks?

Promote it. That subtask was a task in disguise. Pull it out, make it a sibling task with its own flat checklist, and the parent stays clean. This single rule is what keeps the structure capped at one level — depth can only appear if you let children sprout children, so you simply don't.

Does capping nesting at one level actually make me faster?

Yes, in two ways. You eliminate the maintenance tax of grooming a tree, and you keep status and work-in-progress unambiguous, which means less time deciding what to do and more time doing it. The structure can't grow, so it can never become the thing you manage instead of the work.

Deep hierarchies promise control and deliver homework. One level of subtasks gives you the one thing that's genuinely useful — a flat checklist for cracking a too-big task — and then gets out of your way. Cap it at one, promote anything that wants to grow, and let the work be the thing you spend your attention on. Ship, don't groom.