Skip to main content

JIRA story--> Subtasks instead of tasks

Last post 07:52 pm February 9, 2024 by Nikhil Rathod
9 replies
09:10 am March 27, 2020

Hi all,

Our team is taking transition of new project from some other team. Now, that team has created sub-tasks under stories instead of tasks. According to me it should have been Story--> Tasks-->Sub Tasks

If the same practice is followed in future, do you think it would be a problem?

I can only think of this issue - > If we create sub-tasks under stories instead of tasks, we can't drill down more if required in future. But apart from this, is there any other issue that we may come across?



02:02 pm March 27, 2020

Since the Sprint Backlog is owned by the Development Team, it is up to them on how to use it. Your answer depends on how they want to use the issue types and visualize the work.

I have seen most Development Teams use issue types of Story and Sub-task, if the Sub-task is related to the Story. If the sub tasks are a breakdown of the story, then this is a fine way to relate the work to the Product Backlog item, as it has a parent-child relationship. Then the sub tasks can be moved across the workflow.

How would you link the Story to Task in Jira?

03:02 pm March 27, 2020

Since there is nothing in Scrum that says how you actually visualize your Product/Sprint backlogs, there isn't an answer to that question.  As @Chris Belknap said, the team needs to decide how to deal with this.  But I will say that you can always break a story down further in Jira. You can link stories to each other to show the relationship.  And if you are an organization that uses burndown/burnup charts, subtasks aren't represented in the Jira charts but given you statement you already know that. 

11:44 am March 30, 2020

Thanks Chris and Daniel.

How would you link the Story to Task in Jira?

The same way we link sub-task to JIRA. I don't think there is any difference.


Subtasks aren't represented in the Jira charts

I am not sure about that. As per the Atlassian-:

Subtask behavior when remaining estimate and time spent is enabled: parent task will have the total sum of all remaining estimates of the subtasks.

Subtask behavior when remaining estimate and time spent is disabled: 

(a)If you add a subtask to an issue that's already in an active sprint, the subtask is also treated as scope change.

(b) However, scope change is not indicated in the Burndown Chart for the subtask.

(c) Time estimates are tracked individually across the subtasks and the parent task itself.

Reading above information I feel, if we keep updating remaining time , time spent etc for sub-task, the same will get reflected in burn down chart if at all we want to see burn down for hours spent/remaining for each story.




07:18 am October 15, 2021

I would like to recommend another approach:

Instead of sub-task, we prefer to create tasks with "Linked Issues"  field as "split from" and the following "issue" field enter the  parent user story/task.

It may require a little bit more effort to create task, however, far more flexible.

05:33 pm October 15, 2021

Hi, Vishal!

What do you think is more important for your team? Following a particular method to structure your Product and Sprint Backlog or following a method that the team believes would add clarity to its process and improve its communication?

Is not possible to try one option and if it doesn't work as expected try the other one? Is the decision taken about how to structure the product backlog irreversible? Is this actually a paramount problem for the team? 

How the first value of the Agile Manifesto (individuals and interactions over processes and tools) applies to this case in order to facilitate the best decision?


07:27 am October 16, 2021

In my experience, these Work Breakdown Structure detailing has not helped the team much instead it increased the Jira administrative work. Having many layers like task, subtask all could make the transparency hard to the whole team. You and team will be lost after some sprints and stop doing many things. So start with simple and add what is required when your team finds out by learning. The visibility should be as simple as possible so any stakeholders also can understand. 

11:07 pm January 24, 2023

Problem with subtasks is two: 


- can't see them on the backlog view (only epics in the sidebar and tasks/stories in the main list)

- can't reliably create JQL queries that reveal sub tasks of an epic without having to install a massively expensive jira plugin

11:12 pm January 24, 2023

Additionally, you're much better off just : 


- creating stories that define the use case

- creating n+1 tasks linked to the story as "implements" and each tasks can link to other tasks as "blocks", etc.


- you get a progress chart on the story

- all work is visible in the backlog


I honestly don't even understand what Atlassian was thinking when they made subtasks... they've ended up wasting so much of my time.

08:28 am February 9, 2024

The primary purpose of using Scrum tools is to facilitate team collaboration by providing a centralized platform for planning, tracking, and managing Agile projects. These tools typically offer features such as Scrum boards, backlog management, sprint planning, task tracking, and reporting capabilities. By utilizing Scrum tools, teams can improve communication, transparency, and efficiency in their development processes, leading to better project outcomes. There are many tools in the market that are Vabro, Jira, ClickUp,, Zoho etc. Jira is the OG of Scrum Tools space and has been there for two decades. The latest entrant in this space is Vabro, which offers that same feature set as Jira, while bringing something new to the table, namely messaging, cloning, and managing workflows. The one we have been using for a while is Vabro that aims to streamline workflows, improve team communication, and enhance productivity within organizations of all sizes and industries.

By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by may have their access revoked at any time, without warning. may, but is not obliged to, monitor submissions.