Short definition
A Jira sub-task is a child issue attached to a single parent (a Story, Task, Bug, or custom standard-level issue). Sub-tasks break the parent's work into smaller steps - design, build, test, document - so individual team members can claim and track each piece without losing the parent context. Sub-tasks belong to the same project as their parent and inherit several fields.
How sub-tasks behave in Jira
A sub-task is an issue with the Sub-task issue type (or a custom type at the sub-task hierarchy level) and a mandatory parent field. Several behaviours differ from standard issues:
- Project-locked: a sub-task lives in the same project as its parent and cannot be moved to a different project independently.
- Inheritance: sub-tasks inherit assignee, due date, components, and labels from the parent on creation if those fields are blank on the sub-task itself.
- Reporter: separate from the parent. Reporter on a sub-task usually reflects who delegated the work.
- No further nesting: as noted above, a sub-task cannot have sub-tasks of its own.
The parent issue gains a “Sub-tasks” panel on its detail view, showing each child’s summary, status, and assignee. A progress indicator on the parent (the small grey/green bar) shows how many sub-tasks are done.
What sub-tasks are good for
The clearest pattern is phase decomposition - breaking one user-facing deliverable (the parent story) into the engineering phases that complete it:
- Design / spec
- Implementation
- Code review
- QA
- Documentation
- Release-note draft
Phase decomposition gives accurate cycle-time data per phase (the time the sub-task spends in In Progress) and lets a designer, an engineer, and a QA tester claim their respective sub-tasks independently. Reporting on the parent alone hides this detail.
Sub-tasks are not the right pattern for:
- Independent deliverables that ship on different schedules (use separate stories with issue links).
- Cross-project work (sub-tasks are project-locked).
- Repeating chores (use recurring issues or an automation rule, not a parent-with-sub-tasks).
Automating sub-task creation
The reason STM Issue Templates exists: teams almost always agree on a standard sub-task breakdown for each issue type, but typing it out by hand on every new ticket is error-prone and skipped under deadline. STM saves the breakdown as a template and triggers it on issue creation, status transition, or a manual menu button. The result is a consistent work breakdown that the team didn’t have to remember to apply.
See also (Redmoon products)
- STM Issue Templates - Save a sub-task set as a template and auto-create it on every new parent issue via Jira Executors - no copy-pasting from a Confluence page.
- STM template walkthrough - Step-by-step on how an STM template becomes the standard sub-task breakdown for a given issue type.
Common questions
What is a sub-task in Jira?
A sub-task is a child issue attached to a single parent (a Story, Task, Bug, or custom standard-level issue). Sub-tasks break the parent's work into smaller steps - design, build, test, document - so individual team members can claim and track each piece without losing the parent context. Sub-tasks belong to the same project as their parent and inherit several fields.
What's the difference between a sub-task and a linked issue?
A sub-task has exactly one parent and lives inside that parent's project; a linked issue is an explicit relationship (blocks, relates to, duplicates) between two independent issues that may live in different projects. Sub-tasks form a hierarchy; linked issues form a graph.
Can a sub-task have its own sub-tasks?
No. Jira's hierarchy has exactly three levels in its default model: Epic -> Standard issue (Story / Task / Bug) -> Sub-task. Sub-tasks cannot be parents themselves. If you find yourself wanting sub-sub-tasks, the parent should probably have been an epic and the sub-tasks should be promoted to standard issues.
How do you create the same sub-tasks on every new story?
Manually it's tedious and inconsistent. STM Issue Templates solves this: build the sub-task set once as a template, attach it to an On Issue Created Executor scoped to the parent issue type, and STM creates the full set automatically on every new parent. Assignees, due dates, and components are inherited from the parent unless overridden.