Jira Subtasks: Sprints, Story Points and JQL, Tested
On this page
Sprint planning. The story has five sub-tasks, each with an estimate, and the team adds them up in their heads: 13 points. The sprint report later says the story was worth 5. Nobody changed anything. Jira just never counted the sub-tasks.
We tested how Jira treats sub-tasks on our Jira Cloud site on 14 November 2026 and wrote down every result. Twelve rules came out of it.
Short answer: A subtask is a work item one level below a story, task or bug. It takes its parent’s
sprint and nothing else, and it cannot leave that sprint. Its story points are stored, but count
nowhere: not in the parent, not in velocity, not in the sprint report. Finishing every sub-task does not
finish the parent. Converting a task to a sub-task goes through a wizard; changing the parent takes one
step. In JQL use issuetype in subTaskIssueTypes(), not the type’s name, which differs between space
types. If the parts are steps one person ticks off, a checklist is the lighter tool.
The twelve rules at a glance
| # | Rule | Atlassian docs say so | Our site |
|---|---|---|---|
| 1 | A subtask needs a parent and cannot have children | yes | confirmed, with Jira’s errors |
| 2 | It inherits the sprint, not labels, versions or priority | partly | only the sprint came along |
| 3 | It cannot be in a different sprint | yes | one error, one silent success |
| 4 | Its story points count nowhere | yes | 10 points, 0 in the report |
| 5 | Done sub-tasks do not move the parent | not stated | parent stayed In Progress |
| 6 | A Done parent with open sub-tasks is allowed | admin can block it | allowed; the sprint is what blocks |
| 7 | Converting needs the wizard | yes | API refused, wizard worked |
| 8 | The parent can change in one step | no, docs say two | one step worked |
| 9 | Parent and sub-task share one space | implied | cross-space parent refused |
| 10 | Team-managed spaces are stricter, and the type has a new name | yes | epic parent refused, Subtask vs Sub-task |
| 11 | On a company-managed board, sub-tasks are cards | partly | own card, parent chip, own estimate |
| 12 | Past 500 children, the parent stops listing them | yes | not tested |
Twelve rules, each tested
Our test space is a company-managed scrum space with an active sprint and Story Points as the board’s estimate. We created a story with labels, a fix version, priority High and a due date, gave it 5 points, and added three sub-tasks with only a summary. A second, team-managed space covered rule 10.
Rule 1: A subtask needs a parent and cannot have children
Atlassian: “A subtask is a piece of work that is required to complete a task. Subtask work items can be used to break down any of your standard work items in Jira (bugs, stories or tasks).” And: “A subtask can’t have any child work items” (What are work types).
Our site: a sub-task without a parent was refused with “Issue type is a sub-task but parent issue key or id not specified”, and one under another sub-task with “can not be sub-task”. We logged both in Jira epic vs story vs task, along with the surprise that a company-managed space accepts a sub-task directly under an epic. Atlassian documents that too: you can attach sub-tasks to the epic “using the Add parent link”.
Do this: keep sub-tasks for a story, task or bug. Need a third level? See the decision table below.
Rule 2: It inherits the sprint, not your fields
Atlassian: “A subtask will inherit the space, work security level, and sprint value (software spaces) from their parent” (Create a work item and a subtask).
Our site: the parent had the label subtask-test, fix version 2.0, priority High and a due date of 1
December. The new sub-task had no label, no fix version, priority Medium (the default) and no due date. Only
the sprint came along. The request to inherit fields
(JRACLOUD-5225) dates from 2004 and has 624 votes.
Do this: set fix version and labels on sub-tasks yourself, or with an Automation rule on creation. It matters at release time: the release dialog moves sub-tasks by their own fix version, as we saw in Jira fix version.
Rule 3: It cannot be in a different sprint
Our site: setting the sub-task’s Sprint field returned:
Issue ‘SPR-14’ is a subtask and subtasks cannot be associated to a sprint. It’s associated to the same sprint as its parent.
The sprint API was quieter. Moving the same sub-task into another sprint, or to the backlog, returned success (HTTP 204) and changed nothing. A script that trusts the status code will think it worked. Moving the parent to the other sprint took all three sub-tasks with it.
Do this: if a part of the work belongs in the next sprint, make it a task or story of its own and link it. Teams have asked for this since 2012 (JRACLOUD-90857, 276 votes, “Gathering Interest”).
Rule 4: Its story points count nowhere
Atlassian: “Estimates from sub-tasks are not included in the Velocity Chart’s calculation. (Only estimates from parent tasks are included.)” (Velocity chart).
Our site: we gave the three sub-tasks Story Points 2, 3 and 5 through the board’s estimate. Jira
accepted all three, and each board card showed its number. The parent stayed at 5. The sprint report
listed the parent and three other stories, with an open total of 12 points, the four parents. None of the
sub-tasks was listed. Ten points existed only on the cards. JQL still finds them:
"Story Points" is not EMPTY AND issuetype in subTaskIssueTypes() returned the three. Which of the two
story point fields a board counts, and what Jira accepts as a point: Jira story points.
The request to sum them (JRACLOUD-92573) is the most voted subtask request ever closed, with 1,735 votes. Atlassian closed it in 2021 as “Answered” and pointed to an Automation rule: “Summing estimates from subtasks to stories is one of these rules.”
Do this: estimate the story, not its parts. If your team wants parts estimated, use time tracking (sub-task hours roll up to the parent, up to 100 children per Atlassian) or an Automation rule that writes the sum into the parent. The rule overwrites the story’s own estimate and runs against your Automation limit; Jira automation examples counts what such rules cost. The charts are in Jira velocity and burndown.
Rule 5: Done sub-tasks do not move the parent
Our site: we moved all three sub-tasks to Done through the API. The parent stayed In Progress. Then we reopened one and closed it from the board card’s menu (Change status, Done). No prompt, no change: the parent stayed In Progress. Nothing in Atlassian’s subtask pages promises otherwise.
Do this: close the parent yourself, or add Automation rule 6 from Jira automation examples: “Close the parent when the last sub-task is done”.
Rule 6: A Done parent with open sub-tasks is allowed, until the sprint ends
Atlassian: admins “can create workflow conditions to ensure that all sub-tasks are completed before a parent work item can be resolved”, the Subtask Blocking Condition (Configure sub-tasks).
Our site: without that condition, the parent went to Done with one sub-task still To Do. Jira set the resolution and said nothing. Moving it back to In Progress cleared the resolution. The block comes later: “Before you can complete a sprint, all sub-tasks must be marked as Done.” In Jira sprints a Done story with an open sub-task greyed out Complete sprint, while an In Progress story with an open sub-task did not.
Do this: if a parent must not close early, ask your admin for the Subtask Blocking Condition. Before
sprint end, run sprint in openSprints() AND issuetype in subTaskIssueTypes() AND statusCategory != Done.
Rule 7: Converting needs the wizard
Atlassian: to make a work item a sub-task, select the work type icon, then the sub-task type and a parent. The reverse is More actions (•••), Convert to work item. “You can’t convert a work item to a subtask if the work item has subtasks of its own.”
Our site: editing the type through the REST API was refused both ways: “The issue type selected is invalid” (sub-task to story) and “Given parent work item does not belong to appropriate hierarchy” (task to sub-task). The UI opened a four-step page, “Convert Issue to Sub-task”: parent and type, new status (skipped, “Step 2 is not required”), fields (“All fields will be updated automatically”) and a confirmation that listed only the type change. Our task was in the next sprint before the conversion. After it, the task sat in its new parent’s sprint. An old bug report says the sprint stays behind (JRACLOUD-90891, closed as “Not a bug”); we did not see that.
Do this: convert in the UI, one work item at a time. We did not test bulk changes; Atlassian marked a request for bulk conversion Done in JRACLOUD-13245.
Rule 8: The parent can change in one step
Atlassian’s create page says: “Subtasks also can’t be moved directly from one work item to another. Convert them to standalone work items first.” The same page, a few lines up, describes changing the parent from the work type icon.
Our site: the second one is right. Setting the sub-task’s parent field to another story worked in one call, and the sub-task joined the new parent’s sprint at once. The board card’s menu also has Change parent.
Do this: change the parent directly. Check the sprint afterwards, because it follows the parent.
Rule 9: Parent and sub-task live in one space
Our site: a sub-task in one space with a parent in another was refused: “Issues with this Issue Type must be created in the same project as the parent.” Teams asked for the opposite in JRACLOUD-72506 (205 votes).
Do this: for work another team owns in its own space, create a work item there and link it (“blocks”, “relates to”). JQL parent, epics and linked issues shows how to search both.
Rule 10: Team-managed spaces are stricter, and the type has another name
Atlassian: “Unlike in company-managed spaces, subtasks can’t be nested directly beneath work items at the Epic level” (Manage subtasks in team-managed spaces).
Our site: a subtask under an epic in our team-managed space was refused with “Please select valid
parent issue.” Under a task it worked. The type there is called Subtask; in the company-managed space
it is Sub-task. JQL takes either name without an error, so project = SPR AND type = Subtask returned
0 in the company-managed space, silently. issuetype in subTaskIssueTypes() found all 7 across both.
Do this: never search subtasks by name across spaces. Use the function, or hierarchyLevel = -1.
Rule 11: On a company-managed board, sub-tasks are cards
Our site: on the scrum board each sub-task was its own card, with a chip naming the parent and its own estimate badge. The column count included them: Done showed 4, all of them sub-tasks. Atlassian’s Stories swimlane groups them instead: “One parent work item per swimlane containing all of the subtasks” (Configure swimlanes).
In team-managed spaces the board shows subtasks only after “selecting Subtasks from the Group by dropdown”. Showing them without grouping is “In Progress” at Atlassian (JRACLOUD-85702, 1,060 votes). The scrum backlog does not list sub-tasks on their own at all, only under their parent; Jira backlog has the details, and Jira kanban board how column limits can leave sub-tasks out.
Do this: if sub-task cards crowd the board, switch the swimlanes to Stories, or filter them out with
issuetype in standardIssueTypes() in a quick filter.
Rule 12: Past 500 children, the parent stops listing them
Atlassian: “a work item can only display up to 500 child work items”. Beyond that you view them in search. Time tracking stops earlier: “If a work item has more than 100 child work items, you can’t include them in time tracking.” We did not test these limits; a story near either one should be split. Other Jira limits are collected in Jira limits.
Subtask JQL that works
All counts are from our site on 14 November 2026, checked with Jira’s JQL parser in strict mode. Replace the keys with yours.
| You want | JQL | Our result |
|---|---|---|
| Sub-tasks of one story | parent = SPR-13 | 3 |
| Sub-tasks of several stories | parent in (SPR-13, SPR-4) | 4 |
| All sub-tasks in some spaces | project in (SPR, SAM1) AND issuetype in subTaskIssueTypes() | 7 |
| The same by level | project in (SPR, SAM1) AND hierarchyLevel = -1 | 7 |
| Sub-tasks in the current sprint | sprint in openSprints() AND issuetype in subTaskIssueTypes() | 4 of 8 in sprint |
| Sprint work without sub-tasks | sprint in openSprints() AND issuetype not in subTaskIssueTypes() | the other 4 |
| Sub-tasks with story points (ignored) | "Story Points" is not EMPTY AND issuetype in subTaskIssueTypes() | 3 |
| Open sub-tasks in the sprint | sprint in openSprints() AND issuetype in subTaskIssueTypes() AND statusCategory != Done | run before sprint end |
| An epic’s tree, sub-tasks only | parentEpic = PAY-1 AND hierarchyLevel = -1 | company-managed only |
Atlassian also lists new names for the two functions, subtaskWorkTypes() and standardWorkTypes()
(JQL functions). Both parsed on our
site. The parent field “works for both team-managed and company-managed spaces”
(JQL fields).
What people try, and what Jira answered:
| Query | Jira’s answer |
|---|---|
issueFunction in subtasksOf("...") | “Field ‘issueFunction’ does not exist or you do not have permission to view it.” It is ScriptRunner’s. |
parent in (issuetype = Story) | “Expecting ’,’ or ’)’ but got ’=’”. No subqueries. |
parent.status = Done | “Field ‘parent.status’ does not exist”. No parent fields. |
hasSubtasks = true | “‘true’ is a reserved JQL word”. There is no such field. |
The last two are open requests: JRACLOUD-67108 (work items with or without subtasks, 660 votes) and JRACLOUD-18839 (sub-tasks by a field of the parent, 650 votes). More tested parent and epic queries are in JQL parent, epics and linked issues.
What teams keep asking Atlassian to change
Atlassian tracks feature requests in public on jira.atlassian.com. We pulled every Jira Cloud suggestion with “subtask” or “sub-task” in its title on 14 November 2026: 916, of which 145 are still open. These are the most voted.
Read it as a map of the gaps. Five of the nine are rules above: points (rule 4), sprints (rule 3), inheritance (rule 2), boards (rule 11) and JQL. Two requests from 2004 and 2005 are still “Gathering Interest”. Plan around these limits rather than wait for them.
Subtask, checklist item or child work item?
Most subtask trouble starts with using a sub-task for something that is not separate work. Ask what the part needs.
| The part needs | Use | Why |
|---|---|---|
| its own assignee, status and place on the board | Sub-task | a real work item, same sprint as the parent |
| its own estimate that counts in velocity | Story or task, linked | sub-task points count nowhere (rule 4) |
| a different sprint from the rest | Story or task, linked | sub-tasks follow the parent’s sprint (rule 3) |
| another space or team | Work item there, linked | a sub-task must share its parent’s space (rule 9) |
| only a tick by the same person, like a Definition of Done | Checklist item | no card, no status, no estimate to keep up |
| steps inside a sub-task | Checklist item | a subtask can’t have children (rule 1) |
| to group stories under a larger goal | Epic with child work items | the level above, not below |
A story with twelve sub-tasks is often a story that should be split, as Atlassian’s own tip says: “if a task has too many subtasks, it might be a sign that your task can be split into multiple tasks.” The hierarchy itself is in Jira epic vs story vs task, and native action items against checklist apps in Jira checklist.
Where our apps fit
Team Checklist is the checklist side of the table
above. Items have a tick, a due date and one level of subitems, and templates add a Definition of Done in
two clicks. Its “Team checklist is done” workflow validator keeps a work item out of Done until every item
is ticked, and teamChecklistOpen > 0 finds unfinished ones in JQL. Checklist items have no assignee, no
estimate and no card on the board. When a part needs those, it is a sub-task.
Splitting a story that is too big? Agent Ready can propose sub-tasks from a work item’s own text in Rovo, and creates them only after a person confirms. AI clients connected through Atlassian’s MCP server can convert a work item into a sub-task too; our Jira MCP guide lists that tool and the rest.
How we tested
- Site: our Jira Cloud test site (Standard plan), 14 November 2026, about 00:30 to 01:00 CET.
- Spaces: a company-managed scrum space (Story Points as the board estimate, one active sprint) and a team-managed space.
- Created for the test: one story, three sub-tasks, one task converted to a sub-task, one future sprint and one subtask in the team-managed space. Fields, sprints and statuses were set through REST API v3 and the Agile API; one conversion and one status change were done in the browser.
- JQL was checked with the parse endpoint in strict mode and counted with the search endpoints. The sprint report numbers are from the board’s sprint report data.
- Votes and statuses are from the public jira.atlassian.com API on the same day.
- Not tested: deleting a parent (our test account has no delete permission there), the 100 and 500 child limits, time tracking, and the Subtask Blocking Condition, which needs a workflow change.
Sources
- Atlassian Support, Create a work item and a subtask
- Atlassian Support, Configure sub-tasks
- Atlassian Support, What are work types?
- Atlassian Support, Manage subtasks in team-managed spaces
- Atlassian Support, View and understand the velocity chart
- Atlassian Support, Complete a sprint
- Atlassian Support, Configure swimlanes
- Atlassian Support, Log time on a work item
- Atlassian Support, JQL functions and JQL fields
- Atlassian, public suggestions: JRACLOUD-91572, JRACLOUD-92573, JRACLOUD-85702, JRACLOUD-94775, JRACLOUD-7990, JRACLOUD-67108, JRACLOUD-18839, JRACLOUD-5225, JRACLOUD-90857, JRACLOUD-72506, JRACLOUD-90891
Frequently asked questions
Do subtask story points add up to the story in Jira?
No. You can give a sub-task story points, and the board card shows them, but the parent keeps its own number and the velocity chart and sprint report ignore them. Atlassian: "Estimates from sub-tasks are not included in the Velocity Chart's calculation." On our site three sub-tasks with 2, 3 and 5 points left the parent at 5. Atlassian closed the 1,735-vote request to sum them with a pointer to an Automation rule that writes the sum into the parent.
Can a subtask be in a different sprint than its parent?
No. A sub-task always sits in its parent's sprint. Setting its Sprint field returned "subtasks cannot be associated to a sprint. It's associated to the same sprint as its parent." Moving it through the sprint API returned success and changed nothing. To plan the part separately, make it a standard work item, a task or story, and link it. The request to change this has 276 votes and has been open since 2012.
Why are subtasks not showing on my board?
Four common reasons. In a team-managed space the board shows subtasks only when you group by Subtask. The board's filter may leave them out, for example with issuetype in standardIssueTypes(). The scrum backlog never lists them on their own, only under their parent. And on a kanban board a sub-filter can hide done or released work. On our company-managed scrum board each sub-task was its own card with a chip naming the parent.
Can a Jira subtask have subtasks?
No. Atlassian: "A subtask can't have any child work items." Our test of a sub-task under a sub-task was rejected with "can not be sub-task". If you need a third level of steps, use a checklist inside the sub-task, or make the middle level a story with its own sub-tasks.
How do I convert a subtask to a task, or a task to a subtask?
In a company-managed space, open the sub-task, choose More actions (•••) and Convert to work item; for the other way, select the work type icon, choose the sub-task type and pick a parent. Both open a short wizard. Editing the type through the API is refused. A work item that has sub-tasks of its own cannot become one. In team-managed spaces both ways go through Move.
How do I find all subtasks of a story or an epic in JQL?
For one story: parent = ABC-12. For several: parent in (ABC-12, ABC-15). All subtasks in a space: project = ABC AND issuetype in subTaskIssueTypes(). For an epic's whole tree in a company-managed space: parentEpic = ABC-1 AND hierarchyLevel = -1. JQL cannot filter sub-tasks by a field of their parent without an app.