Stop Double Counting Hours With Subtask Governance for Project Managers
The best practice for subtasks is simple: create one only for work that is discrete, independently assignable and estimable, log effort and dates at that leaf level, and let the parent task roll those numbers up automatically. This keeps handoffs clean, because every piece of work has exactly one owner, and it keeps reporting honest, because totals are never counted twice.
TL;DR:
- Subtasks should only be created for discrete, estimable, and assignable work with a clear owner and measurable deliverable; avoid unnecessary nesting.
- Effort tracking must be logged solely at the subtask level, with parent tasks deriving their totals from their children’s reported effort to prevent inflated estimates.
- Use a short WBS dictionary for each subtask, clearly defining scope, deliverable, acceptance criteria, owner, estimate, and evidence to avoid ambiguity.
- Assign a single owner per subtask, document acceptance criteria upfront, and promote subtasks to independent tasks when their scope exceeds a single estimable step.
- Limit subtask nesting to two or three levels, document lifecycle and roll-up rules explicitly, and run pilot projects to refine your process before large-scale implementation.
Table of Contents
- What subtasks are and how they behave in a task hierarchy
- When to use a subtask and when to make a separate task
- Creating subtasks without the busywork
- WBS dictionary: defining scope and acceptance criteria
- Estimating, scheduling and roll-ups: track leaf, aggregate parent
- Ownership, handoffs and acceptance
- Lifecycle and status propagation rules
- Best-practices checklist: do’s and don’ts to apply now
- A practical pilot beats a perfect policy
- A straightforward option for running your subtask governance
- FAQ
- Sources
What subtasks are and how they behave in a task hierarchy
A subtask is a leaf item: a discrete piece of work nested under a parent, or summary, task that acts as a container. The parent holds the overall deliverable and timeline; the subtask holds the actual, assignable step. Most tools let you track an assignee, status, estimate, start and due dates, labels, comments and time entries on each subtask.
Summary tasks typically don’t carry their own effort. Instead, their dates and totals derive from the children beneath them, according to the work breakdown structures overview from Microsoft Learn, which describes summary-task dates rolling up from the earliest child start and the latest child end. Treat the parent as a reporting shell, not a place to log hours.
When to use a subtask and when to make a separate task
Not every step deserves its own subtask, and not every subtask deserves to stay one. A quick decision checklist helps:
- Can one person own it without needing another team’s sign-off first?
- Can you estimate the effort with reasonable confidence?
- Does it produce a measurable deliverable or checkpoint?
- Does its lifecycle (start, review, done) align naturally with the parent’s?
If you answer “no” to any of these, it may belong as a separate task, a project, or simply a comment. PMI’s guidance on work breakdown structures frames the stop rule clearly: stop decomposing once an item is independently estimable, assignable and controllable. A good subtask is “draft the client proposal”; a bad one is “think about proposal”, which has no owner, no deliverable and no way to mark it done.
Creating subtasks without the busywork
Keep subtask creation fast but disciplined. A few fields matter far more than the rest.
- Name it with a verb first (write, review, approve) and a concise scope, not a vague noun phrase.
- Assign one owner, never a group or “whoever’s free”.
- Write a one-line acceptance criterion: what “done” looks like.
- Add an estimate, even a rough one, so roll-ups mean something.
- Link it to the correct parent task before you add any other detail.
- Add a due date only if the subtask genuinely needs one; skip it for pure checklist items.
Pro Tip: If you can’t finish the subtask’s name in under eight words without adding “and”, it’s probably two subtasks.
Before adding a subtask, ask whether it’s trivial enough to be a checklist line instead. A list bloated with one-click checkpoints is harder to maintain than a shorter, meaningful one.
WBS dictionary: defining scope and acceptance criteria
A one-line task name invites ambiguity once a project has more than a handful of contributors. PMI’s practice guidance on work breakdown structures recommends a short WBS dictionary entry for each element, covering scope, deliverable, acceptance criteria, owner, estimate and evidence of completion.
For subtasks, this doesn’t need to be a formal document, just a consistent, short template:
- Scope: what is and isn’t included in this piece of work.
- Deliverable: the concrete output (a file, an approval, a deployed change).
- Acceptance criteria: the specific condition that proves it’s done.
- Owner: one named person, not a team.
- Estimate: hours or days, logged once.
- Evidence: a link, screenshot or sign-off confirming completion.
If you need a worked format for acceptance criteria specifically, a practical guide to software acceptance criteria types walks through common structures teams can adapt for subtasks beyond pure software contexts.
Estimating, scheduling and roll-ups: track leaf, aggregate parent
Log effort only at the leaf level. Parent and summary tasks have no effort of their own; they aggregate whatever their children report. Entering an estimate on both a subtask and its parent is the single most common cause of inflated totals in status reports.
Scheduling engines typically calculate a summary task’s dates from the earliest start date and latest end date among its children, according to Microsoft’s work breakdown structures documentation, which also notes that predecessor relationships, not simple sibling ordering, determine when a dependent subtask can begin. A related Microsoft Learn article on scheduling a project with a WBS explains that a task with predecessors defaults its planned start to the latest end date among those predecessors.
In practice, this means mapping dependencies explicitly rather than relying on the order subtasks happen to appear in a list. When mixing auto and manual scheduling, watch for subtasks that get manually pinned to a date and then silently stop reflecting changes to their predecessors; that’s a frequent source of roll-up errors that only surface when a report looks wrong.
Ownership, handoffs and acceptance
Clean handoffs depend on unambiguous ownership. Assign a single accountable owner per subtask, and name a backup only where the work is genuinely time-critical.
- One owner per subtask; shared ownership usually means no ownership.
- Mark completion only against the written acceptance criteria, not a gut feeling.
- Require evidence (a link, a file, an approval) before closing, especially on client-facing work.
- Promote a subtask to its own task, or even its own project, once its scope grows beyond a single estimable step.
Pro Tip: If a subtask needs its own subtasks, it has already outgrown the role and should become a parent task in its own right.
Lifecycle and status propagation rules
Different tools handle subtask lifecycles differently, and this is where unexamined defaults cause confusion. IBM’s documentation on subtasks describes systems where a parent task waits for all its subtasks to reach a terminal state before it can complete, and where actions like suspension, termination or deletion on the parent may or may not propagate down to subtasks, depending on configuration.
Decide, and write down, two things before rollout: whether parent completion requires every subtask closed, and which status source is canonical when a child and parent disagree. Document the answer in your team’s working agreement, not just in the tool’s settings, so new members don’t have to guess.
Best-practices checklist: do’s and don’ts to apply now
A short audit against these points catches most subtask problems before they cause reporting headaches.
- Do name subtasks with a verb and a concise scope.
- Do assign exactly one owner per subtask.
- Do write a one-line acceptance criterion before marking work in progress.
- Do estimate and log effort at the leaf level only.
- Do document your lifecycle and roll-up rules once, for the whole team.
| Do | Don’t |
|---|---|
| Keep subtasks independently estimable | Create checkpoint subtasks with no owner or deliverable |
| Log effort once, at the leaf | Duplicate estimates on parent and child |
| Promote scope creep to a new task | Let nesting go beyond two or three levels |
| Write acceptance criteria up front | Mark “done” without evidence of completion |
Bake these into your project template so new boards start compliant rather than needing a retrofit later.
A practical pilot beats a perfect policy
Most teams over-decompose, not under-decompose. The instinct to track everything produces subtask lists nobody maintains, which is worse than a shallower structure with reliable ownership. Rather than drafting a lengthy policy, run a 30 to 60 day pilot on one active project, apply the naming, ownership and roll-up rules above, and adjust before rolling it out further.
— Greg
A straightforward option for running your subtask governance
If you’re testing these conventions, Seven gives us a flexible workspace built around privacy rather than vendor lock-in, which matters once a project’s structure becomes something you depend on daily.
- We let you import existing task lists straight from a spreadsheet, so a pilot doesn’t start from a blank board.
- We built file attachments and messaging into each task, which keeps acceptance evidence next to the subtask it belongs to.
- We never mine your project data for analytics or AI training, and we don’t lock your data into our platform.
- We price plainly: $5 AUD per month for individuals, and $9 AUD per user per month for teams.
Start a pilot on our pricing page and apply the checklist above to one real project before deciding whether it sticks.
FAQ
What is the difference between a subtask and a regular task?
A subtask is a leaf item nested under a parent task, while a regular, standalone task carries its own full lifecycle without a container above it. Use a subtask when the work is a discrete step within a larger deliverable; use a separate task when it needs its own independent timeline or owner structure.
Should I log estimates on both the parent task and its subtasks?
No. Log effort only at the subtask, or leaf, level, and let the parent aggregate those numbers, because Microsoft’s work breakdown structure guidance notes summary tasks have no effort of their own. Duplicating estimates on both levels is a common cause of inflated totals.
When should a subtask become its own task?
Promote a subtask once its scope grows beyond a single estimable, assignable step, for example when it needs its own sub-steps or a separate timeline. PMI’s guidance on work breakdown structures frames this as the point where an item is no longer independently controllable at its current level.
Do all tools handle subtask completion the same way?
No, behaviour varies by platform. IBM’s subtask documentation describes systems where a parent waits for every subtask to reach a terminal state, and where suspension or deletion may or may not propagate, so it’s worth documenting your team’s chosen rule rather than assuming a default.
What should a minimal subtask record to stay useful?
At minimum, record a clear name, one owner, an acceptance criterion and an estimate. Everything else, including comments, attachments and time entries, is useful but optional depending on how closely the work needs tracking.
Sources
- Work breakdown structures overview | Microsoft Learn
- Work breakdown structure: Define the work before you build it | PMI
- Subtasks - IBM Documentation