What is the distinction between Task and Sub-tasks?

[Deleted user]

I'm new to Jira and Greenhopper in particular. When I "Create an Issue" for Type I see four Issue Types: Bug, Enhancement, Epic, Task. If I create an Epic I can add Stories as "children". Under Stories I can add Sub-tasks. I can find docs about Sub-tasks but there is hardly any mention of Task issue types.

How are Tasks to be used and how do they relate/differ from Sub-tasks? In my thinking I would picture the hierarchy as Epic / Story / Task / Sub-task but apparently that isn't what is intended here. From what I can tell it's Epic / Story / Sub-task or Epic / Task. Is that correct? If so, what is the intended use case and differences for when to use these?

Given that Stories are non-technical issues and Epics are groups of Stories, where are you supposed to put technical descriptions of what you plan to do to resolve the issue and provide a way to further break that down into sub-tasks?

Given that our team likes to assign and track effort and time, we have found Sub-tasks don't allow assigning effort points nor does it show anywhere except on the Story they are based on (the parent). You can't see them in the Backlog. You have to view the Story or search for them to find them.

What is the expected methodology to use?

[Renjith Pillai · Accepted solution]

It's like this:

Level 1 - Epic

Level 2 - Enhancement/Task/Story - In fact this can be anything based on the issue types in JIRA. These are just the default ones

Level 3 - Sub-tasks

It just follows the same terminology and practices in Scrum. Till the story has not matured enough to be broken down as technical tasks, keep addiing all information in the Story itself. This keeps it simple.

https://confluence.atlassian.com/display/AGILE/JIRA+Agile+101

[Deleted user]

Thanks for the explanation!

We suffer from team confusion around what goes in an epic vs story and how to relate that to tasks (which are fairly self-explanitory). We generally or intuitively want to place Tasks under Stories which are non-technical generally. So Tasks are done to implement the solution for the Story. Epics seem to be a higher level "folder" of stories with a description at a higher level of abstraction.

I suppose we will continue to wrestle with how to make this work for us.

[Jirong Hu]

This is unbeliebale! Why JIRA can't follow the Scrum standard to use a epic-story-task structure?!

[Renjith Pillai]

It is following the same structure. Epic - Story - Task. That is exactly what I explained on the top.

[Victor Grazi]

@Renjith Pillai Your explanation is excellent, but in defense of @Jirong Hu, he is inquiring why it is not Level 1 Epic, Level 2 Story, Level 3 Task, Level 4 subtask. I think your answer to that is, that you are free to introduce any degree of nesting that you like.

[Brion Swanson]

I agree with @Victor Grazi - There are 3 levels in JIRA, but use of JIRA in a Scrum fashion really uses 4 "levels": Level 1 - Epic (Issue type in JIRA), Level 2 - Story (Issue type in JIRA), Level 3 - New Feature/Improvement/Bug/Task (Issue type in JIRA), Level 4 - Sub-task (sub-task type in JIRA)

[Ronny Katzenberger]

Why the outrage? Hold your horses.

A Story and Task are clearly different. And people need to stop calling everything a "story" in Scrum. Not every effort in Scrum is a story.

Story

The term "story" comes from "User Story". A user story follows the format "I as WHO want to do WHAT, so that WHY. A user story deliveres value to the customer/user. It's a product requirement from the customer/user.

Task

A task is not written in the user story format. A task has more a technical nature.

For example "Update Atlassian Confluence to 5.4" or "Submit app to app store".

Sub-Task

I usually advise my team to use sub-tasks as a tool to organize their own work. This will help to better structure a bigger story/task.

Let's say a team member is working on a 5 or 8 SP story and gets sick the day after he started. It will be easier for a person who continues this story to find out where he left off when having sub-tasks on it.

You can also use sub-tasks to assign out work to other groups or SMEs when you need their help in order to call your task/story done. This way you will be still the owner of the main JIRA issue but the SMEs have something assigned to them in JIRA and use it in their own workflows or metrics.

My five cents.

[Deniz Yalçın]

The problem with the current categorization in Jira is this : Normally in Scrum you do define tasks for (user) stories which then are tracked by a simple two level tree logic. There is the (user) story which is represented by the Product Owner and there some tasks which are worked on by the Scrum Team for that (user) story. When you try to visualize this in Jira you are confused by a new term of "Sub-tasks" for (user) stories because tasks are created at the same level with (user) stories. To bind tasks to the (user) stories you have to create separate relations from tasks to the (user) stories and yet they aren't shown on the issue list one level under the (user) stories. They are shown to be at the same level with them. You can't visualize the (user) story - task grouping (to my knowledge at least). If you use the sub-tasks in place of tasks because they can be shown to be one level under the (user) stories then you lose the ability to track task-(user) story completion and relation status.

[Jason]

agree with this. it's confusing in Jira.

[Gregory Demotchkine]

There are dfferent methodologies and different useage scenarios.

that's why software must be flexible and not rigid. Admins should be able to define levels of hierarchisations. A subtask is by definition the child of a task and do not need to be followed by PM. Tasks linked to stories are most often sections of stories or different stages of implementations.

So what we need to is a flexible 4-level hierarchisation. Epic-Story-task-subtask.

Why does something so logical is not implemented? why limit and bottleneck us and fight against how people may use?

SOFTWARE MUST BE FLEXIBLE!

[Art Campbell]

Totally agree! This is a logical structure, and it's certainly not overwhelming. It makes no kind of sense to have sub-tasks that don't map back to, or aren't part of, a parent task.

[William]

I am new to JIRA so excuse my ignorance, but...

Along Bruce's line of thinking.  Our department uses Epic / Story / Subtask.  The problem with this is that disruptive tasks are a very common occurrence and need to be included / connected to the subtask.  But Issues/Tasks cannot be connected to Subtasks. 

We are considering the Epic / Story / Task / Subtask path.  Take into account we are using the JIRA email auto creation to create Issues/Tasks that after the fact will be including in the above workflow.  The email created Issues/Tasks will be converted to a Subtask to flow under the task.  Will this work?

[Rui Aguiar]

Yes, WHY limit a free 'tree' hierarchy? I find it to be the most useful feature when I need the flexbility to organize anything (tasks, requirements, anything)

I think it is not available because it poses UI challenges, because, conceptually, it makes all the sense not to have sucha a limitation.

@Justin, in which way(s) can that be made to work?

[Luke Nieuwsma]

Be warned - if you convert from stories into tasks... you will lose your story points!

[Kaustav Bose]

it really should be Epic/Stories/tasks. Epic and stories are related but have a hierarchy. Tasks are the actual units of work to be tracked. If you think sub-tasks are part of a task, from a Scrum standpoint, that doesn't make sense because you shouldn't have to break a task into sub-tasks. If you think you need to, then your perception of a task is not correct and it needs to be broken into simpler tasks. From JIRA's standpoint it seems that a task is something else.

[Yasmine Rifai]

So in Jira there is no hierarchisation? Because II need to set everything up for Jira for our company, and I need this hierarchy.

[Justin Leader]

Yes, there is hierarchy in JIRA, but in general there is not "unlimited" hierarchy. I can't speak for Atlassian, but limiting endless hierarchial levels allows users to focus on other ways to organize issues. There are many tools in JIRA's toolbox with which to organize issues, and after doing some strategy, I've never had a client unable to find a good solution.

And if you truly need unlimited hierarchies in JIRA, we can make that work too, although that's not my preferred method.

[Deleted user]

Given our team's dislike for Sub-tasks for the above mentioned reasons, we essentially have Epic / Story or Epic / Task. That seems limiting given Stories are non-technical requirements. Where can you break down the Story to design and implement a solution for the Story requirement(s)?