What is the point of sub tasks?

[ChristopherChilds]

Hi Jira Community,

Not sure if the Discussion area gets much traction. This is not an issue, so this is the right place for this.

I have been working as a Jira Admin for just over a year now and I am struggling to understand what the point of Sub-Tasks are in Jira.  Why do they have strange Characteristics which the other issue types do not have?
Why are they not just the same as any other issue, but called Sub Tasks.

I am sure there are many more, but here are some strange things I have seen. Unfortunate y my list is limited at the time of writing but I am sure there are many others;

- Completed Sub Tasks just hang around on Sprint boards like a bad smell.

- Some time JQL do not pick up sub-tasks in queries

- from the Board view one can not really easily click to the parent (the link is in the path) and you have to open the issue to then select the link to the parent.

- Some plugins do not interact with it well

Is this just a historical feature like the Field Configuration, which in most cases is just not used?

[Florian Bonniec]

Hi

Sub-task block the completion of the Sprint because if a sub-task is not complete, that means the Task or Story this subtask is part of is not complete. Because in Agile we deliver only completed story (90% of the task deliver 0% value to customer) it ask you to move the Story to another Sprint or Backlog.

JQL should work the same with sub-task than Task, if the subtask is not returned in a filter that means it do not match the query.

Regarding the board you can configure it to show swimlane by story, it will be easier to reach the parent but it may be some UX issues on this one.

I don' t know which plugin you are referencing too but most of the well known apps manage them.

I do not really cacth your note regarding Field Configuration as I use them quite often.

Basically an issue type of type Sub-Type behave like a standard task. The difference being the fact that they have to have a parent. With this parent having to be within the same project. Another difference between Tak and Sub-task is that a Sub-task cannot have SUbtask.

Regards

[Ismael Jimoh]

Hi @ChristopherChilds 

A sun-task is fundamentally a task but it is a part of a whole.

Lets say you want to setup a Jira Server instance (main task), while analysing, you realise oh I need a database and a server where the application is hosted. User directory.

Each of these could be sub-tasks to the task Setup Jira Server. You can then go ahead and even assign these tasks to the various users who would need to handle them.

Now I am not going to say sub-tasks are perfect but understanding when to use them and how they are expected to work will be a great help.

To some of your points:

1. Sun-tasks hang on your board even when completed.

 I will suggest looking at the board filters and if you are using Kanban, look at the filter for done status and ensure this encompasses sub tasks too.

2. JQL don’t pick subtasks

This should never be the case. If JQLs are constructed correctly, they should always give you the correct data if somethings isn’t wrong like a broken index. Remember to look at the various operations and function used in your JQL to ensure one or the other isn’t filtering wrongly.

3. Click on sun-task parent

Personally, I am not a fan of clicking on things from the board view. I recommend that you open the page of the issue and select what you want from there. If you must, check if you can add the patent issue to the small section that appears to the right side of your board. The one providing a summary of the ticket.

There’ll be other aspects I don’t fully cover but in the end, I try to understand Atlassian or my customers use case and then explain it as I did above user if there are common grounds found and assist with any points that require clarity 

[Nic Brough -Adaptavist-]

> Not sure if the Discussion area gets much traction.

They do.

As someone who feels like they spend a lot of time trying to explain sub-tasks to people who don't really understand Agile, I think you've not only just highlighted that discussions get neglected, but also picked on a very good subject to try to re-invigorate them!

>This is not an issue, so this is the right place for this.

Yep, totally with you.  Jira does sub-tasks right, it's not an issue with Jira.  It's an issue with people not really understanding them.  Often because they've come from weaker tools that let them pretend to be Agile.

>I have been working as a Jira Admin for just over a year now and I am struggling to understand what the point of Sub-Tasks are in Jira.  Why do they have strange Characteristics which the other issue types do not have?

My short answer to this is "because they are a botch".  But there's some history.  Jira is a bit younger than the Agile manifesto, but also didn't really properly go Agile until several years later.  When it did, it hung on to the non-Agile practice of creating sub-tasks because, well, people like them (they can make a huge amount of sense when you think "they are a part of their parent").  Agle processes don't have much to say about sub-tasks, but they absolutely tell us to use them if they're useful for us.

>Why are they not just the same as any other issue, but called Sub Tasks.

You can call them what you want in Company managed projects.  But the reason they work differently is because they're not issues, they're fragments of other issues.

> Completed Sub Tasks just hang around on Sprint boards like a bad smell.

I can't ague that one, they can, if you don't think about board setups and what sub-tasks are for.

>Some time JQL do not pick up sub-tasks in queries

This probably means that "sprint = X" won't find them.  This is correct - sub-tasks only go into sprints as part of their parent issue, they're not sprint items.  I regularly argue that this is a howling bug in Jira - the sub-tasks should have a sprint field so that we can report on them (but the sprint field should never be enterable, it should just be a copy of the parent issue sprint)

> from the Board view one can not really easily click to the parent (the link is in the path) and you have to open the issue to then select the link to the parent.

I agree with you on that too - it feels clunky.  I kind of understand the view "part of another issue", but it wouldn't hurt to let us click through easily.

>Some plugins do not interact with it well

Yeah, that's a really interesting one.  But I'm going to come across as a complete cynic on this one.  The plugins that "don't interact well" are the plugins that are pretending to try to "improve" things by, in reality, not being Agile.  They don't interact with sub-tasks well because they're reverting your attempts to be agile back to the failure of waterfall.  The best answer on those is actually "stop using these apps, they're doing you a disservice"

>Is this just a historical feature like the Field Configuration, which in most cases is just not used?

No.  It's woven into the fabric of Jira.

(Complete aside, I don't know where you get "Field Configuration, which in most cases is just not used" from, as I have yet to see a Jira that does not use them)