Why this matters for engineering teams
The hardest part of a sub-task breakdown is making it consistent. Every engineering org agrees in principle that “all bugs should have triage, investigation, fix, regression-test, and release-note sub-tasks.” Almost none execute on that consistently in practice, because the agreement lives in a Confluence document and the execution requires typing out the sub-tasks on every new bug.
The friction kills the standard. Engineers under deadline skip the breakdown. Reporters from outside the team don’t know the breakdown exists. Sub-tasks appear haphazardly, and cycle-time reports become meaningless because the same phase is sometimes a sub-task and sometimes not.
STM closes the gap by automating the creation. The standard breakdown isn’t a doc; it’s an Executor. Every new Bug ticket has the breakdown, every new Story has its breakdown, every new Incident has its postmortem sub-tasks. The standard becomes the default rather than the exception.
The cycle-time payoff
The reason most teams adopt STM is the side effect on data quality. Once every Bug has the same sub-task breakdown, Jira’s cycle-time reports become useful:
- Time in “QA Triage” sub-task = triage cycle time.
- Time in “Engineering Investigation” sub-task = investigation cycle time.
- Time in “Fix Implementation” sub-task = build cycle time.
- Time in “Regression Test” sub-task = QA cycle time.
These are the metrics engineering leaders want for retros and capacity planning. Without consistent sub-tasks, you get one opaque “In Progress” duration per bug; with STM, you get a phase-by-phase breakdown.
When to use the manual trigger
Not every breakdown should be automatic. Some good candidates for the manual trigger:
- One-off architecture reviews that don’t happen often enough to warrant an Executor.
- Spike investigations whose sub-task set depends on the spike’s findings.
- Customer-escalation breakdowns that vary by escalation severity.
For these, STM still wins over manual sub-task creation: the breakdown is one click instead of five typed sub-tasks. The engineer picks a template from the issue menu instead of typing.
What engineering teams are dealing with today
- Engineering teams agree that every story needs design, build, QA, docs, and release-note sub-tasks. Nobody types them out every time.
- Sub-task creation is manual: a story gets the breakdown if the assignee remembers, and a different breakdown if a different engineer picks it up.
- Bug tickets need a triage / investigation / fix / regression-test breakdown. Same problem.
- Cycle-time data is meaningless because phases aren't broken into sub-tasks consistently.
- Process documents in Confluence describe the 'correct' breakdown, but the breakdown doesn't actually appear on tickets unless someone copy-pastes from the doc.
How STM helps engineering teams
Sub-task templates with field defaults
Save a reusable sub-task template with summary, description, default assignee, default due-date offset, and field defaults. Use it across hundreds of parent issues without re-typing.
Trigger on issue creation
Wire a template to an On Issue Created Executor scoped to specific issue types. Every new Bug creates the full triage sub-task set; every new Story creates the build/test/docs/release breakdown.
Trigger on workflow transition
Wire a template to a status transition. When an issue moves to 'Ready for QA,' STM creates the QA sub-tasks. When it moves to 'Ready for Release,' STM creates the release sub-tasks. Phases get sub-tasked at the right moment.
Manual trigger from the issue menu
An engineer can pick a template from the issue's menu and instantiate it on demand. Useful for ad-hoc breakdowns that don't fit a transition trigger.
Inherit-from-parent semantics
Sub-tasks inherit assignee, due date, components, and labels from the parent unless explicitly overridden in the template. The defaults match what reporters would set manually.
Use cases
- Bug triage breakdown. On bug creation, STM creates: QA triage, engineering investigation, fix implementation, regression test, release note. The engineering team gets accurate cycle-time per phase and never argues about scope.
- Story implementation breakdown. On story creation: design review (if needed), implementation, code review, QA, documentation, release note. The story's progress bar reflects real phase-by-phase status.
- Incident postmortem. On incident resolution, STM creates: 5-whys analysis, root-cause documentation, action items, postmortem review meeting, closeout. The postmortem isn't forgotten because the sub-tasks make it obviously incomplete.
- RFC / technical design. On RFC creation, STM creates: draft, internal review, stakeholder approval, publication, follow-up implementation tickets. The design process becomes traceable.
Common questions from engineering teams
Does STM modify the parent issue?
Not by default. STM creates sub-tasks; it doesn't change the parent issue's fields, screens, or workflow. The parent's Create Issue screen is configured in Jira's project settings (which is a Jira admin task), and STM operates entirely on the sub-task side.
How is this different from Jira Automation's create-sub-task action?
Jira Automation can create sub-tasks, but each rule is per-sub-task and breaks down at scale. STM treats the sub-task *set* as a first-class template: ordered list, field defaults per sub-task, inheritance rules, manual trigger from the issue menu. For more than 2-3 sub-tasks, STM is much less fragile than Automation rules.
Can STM apply different templates to different issue types?
Yes. Executors include conditions: 'when issue type is Bug, apply the Bug Triage template; when issue type is Story, apply the Story Implementation template.' Multiple Executors can apply to the same project, scoped by issue type, JQL filter, or transition.
Does STM work on Jira Cloud and Data Center?
Yes - two listings on the Marketplace, similar functional surface. STM Lite is a simpler Cloud-focused version for teams that want manual sub-task templates without the Executor automation; STM (full) supports both Cloud and Data Center with the full Executor capabilities.
What happens if a template references a field that doesn't exist on the destination screen?
STM applies the field value to the sub-task data regardless of screen presence. The field exists on the sub-task even if the project's Edit screen doesn't show it - the value is set and queryable via JQL. For most engineering use cases, this is the desired behavior.
Try STM for your team
STM works for engineering teams on Jira Cloud and Data Center. Install from the Atlassian Marketplace, or read the main STM page for the full feature list.
Try STM on the Atlassian Marketplace ↗ See the full STM overview →
Also built for
STM solves a different problem for each team: