+1

Please remember that if you want this feature in Jira Cloud, you need to vote here: https://jira.atlassian.com/browse/JSWCLOUD-5797

This is a very important feature in Jira that is missing!

+1

This is a very important feature for the marketing industry!

I understand the SCRUM purist mentality on this but Jira is used by more than just software engineering teams.  If a team using Jira has another planning approach for stories or any issue type that has subtasks for that matter, the system should allow those subtasks to either inherit the parents sprint, OR allow for subtasks to have their own sprints.  I cannot believe this 'suggestion' has been open for 10 years...

This self-imposed limitation in Jira is ridiculous.

Whether or not some feature or capability aligns with the scrum ideology, or any ideology for that matter, should not be the basis for allowing or restricting it. The question is, can it help people do what needs to be done given their particular situation.

Without even discussing the justification for including subtasks directly in sprints, it shouldn't be fundamentally restricted. Developers do not know every scenario a team may find themselves in or when a feature may be helpful / better than the prescribed methodology.

Since many people want this feature, and since this feature comes with relatively practical and relatable use cases, and since deliberately restricting this feature would be for the sake of ideological conformity...  it should have remained optional.

Jira can go ahead and throw up a warning any time you deviate from scrum methodology by enabling a feature or it can offer the prescribed method as an alternative, allowing the user to then happily click the button labeled, "Cool. I don't actually care but thanks. I'll take my chances."

Allow the tool to be as flexible as possible where it's easy enough to allow it. It may not align with the tool's original intent, but it may meet unforeseen needs or open the tool up for more novel uses, widening its market appeal.

All that said, my use case for subtasks seems pretty similar to all the other folks who ask for it. Alternatives like those proposed here seem very problematic.

Ultimately, we want a single Jira issue / ticket to represent a single deliverable (e.g. Create a an Inventory PowerBI Report for the Operations Department). 

We want subtasks to represent a chunk of work for that deliverable which can be accomplished in a single sprint (e.g. Gather requirements and research potential solutions).

It's uncomplicated and intuitive. Why subtasks are assumed to all be tiny little steps not worth pointing or tracking in a sprint is bizarre. Even simple steps can turn into more than we assumed they would be during a sprint, giving need to slap points on it and see it in the sprint so our managers know where our time is going.

Yes, we could use epics to represent each individual deliverable. The tickets within that epic would then be considered the measurable subtasks for sprint purposes. The problem here, though, is that...

(1) We want to use Epics to represent larger scale initiatives or groups of related deliverables (e.g. Replace SSRS Reporting System Company-Wide). More than just preference, large scale initiatives like these show up quite naturally on our Jira Road Map. It gives us broad oversight into all the initiatives we have planned and currently in progress. It allows us to conveniently manage the start and end date of large scale initiatives, see how they fit into our sprints, and see the individual deliverables (i.e. Issues) involved in each and where they fall into the initiative's timeline.

Suggesting that we upgrade to the more costly version of Jira or use an addon to manage large scale initiatives (i.e. essentially create epics of epics), seems a very heavy-handed and costly solution, just to avoid breaking scrum ideals, putting points on subtasks and making them visible in sprints.

(2) If we were to make an epic for every single deliverable in our backlog, that would be 100 epics right there. Our Jira Road Map would be unbelievably large, giving no broad and automated oversight into the actual initiatives each deliverable was for. We could not use the road map to actually... road map the large scale projects we aim to complete in the coming months. The road map would become nothing more than a view of the backlog / planned sprints in the form of a morbidly obese calendar.

(3) Managing the relationship between individual Issues and their Epics is more work and less intuitive than simply clicking the "Create Subtask" button on an Issue. The relationship is immediately established by clicking that button on an Issue. Moreover, you can easily arrange the order of subtasks on the Issue by clicking and dragging them. I don't believe you can do that with the Issues displayed in an Epic. They are stuck and get cluttered really fast.

Yes, we could use a dozen other workarounds, but we lose intuitive usage, ease of management, and the benefit of built-in automated tools like the Road Map.

The scenario we're in over here does not seem unusual to me, so I'm puzzled as to why it's difficult for some to relate to the problem. You either use epics to track large scale initiatives for broad department oversight, losing the ability to break up individual deliverables into sprint-managed subtasks, or you turn the road map into a vomit of disconnected deliverables, but gaining the ability to treat each Issue like a pointed, sprint manageable subtask of the deliverable. 

Linking several Issues together is unwieldy and not something that gives clear oversight on what Issues are deliverables and part of an epic and which are just subtasks.

If we're missing something obvious here, I'm not above admitting I'm a moron, so have at it.

+1

+1

+1

A finished User Story represents some value for the customer.

In cases when that value can not be achieved unless both UI and API systems are changed, it makes sense to split sub-tasks of the User Story to different sprints.

Instead of committing to completing the whole User Story in the sprint, we can correctly adjust the workload of the sprint by adding some sub-tasks of said User Story. For example, sub-tasks that involve the API first, then sub-tasks involving UI would be done in a later.

We need this because we work as supporter for other projects. We get subtasks from the other project's story and want to plan it into our sprint without the whole story.

+1

When to expect this? 

+1

I manage sprints for multiple Data teams and the ability to allocate sub-tasks to sprints outside of their parent would be HUGE. 

+1

Major +1

+1

+1

Same needs made us to come up with own JIRA add-on called Pivot Report. You can check demo report for Backlog here. No registration needed, just click and see it in action.

Pivot Report is available both for Cloud and Server. You can evaluate it via Atlassian  Market. 

If you have any questions on the add-on, feel free to send me an email to dmitry@pivotreport.com

+1, this is a serious issue for us, especially considering the lack of hierarchical levels we can use for our WBS on large projects. Because of this, subtasks are pretty much unusable when using Agile.

Just added this one to the list of "Features" that renders JIRA basically useless for Software development. I think we are approaching the pain limit for when to scrap JIRA en move on to something else. I think the problem her is total lack of understanding about how Agile Scrum works in real life.

adam1443306598, this request is for the inclusion of sub-tasks in a sprint independently of its parent issue.
Please see the related issues for visibility of issues in the Backlog and estimation visibility and roll-ups:

https://jira.atlassian.com/browse/GHS-7992
https://jira.atlassian.com/browse/GHS-9167
https://jira.atlassian.com/browse/GHS-7719

Kind regards,
Martin
JIRA Software

+1 to please reconsider.
This feature would really accentuate how it is that many users including myself would like to see the subtasks shown. It is possible to work around this but to plan the sub task using time (story points) and not have either rolled up in the Backlog and Board seems to make the SubTasks useless.
Please elaborate on why they are even here if this feature isn't feasible? The option of rolling everything up a level isn't really possible in this scenario (and others' scenarios).
Please reconsider this - thank you

+1! we are struggling with this issue, and renders the sub-tasks unusable

Please consider adding this functionality as well as showing the subtasks on the planning board. This is a serious pain point for managing large complex programs in Jira Agile that span teams or have complex workflows. I would love to have the concept of themes as well so I could track / report progress of the major program objectives.

+1 to show subtasks on the board and ability to add to sprint.

I would love to see this improvement in near future.

Have just one level of Sub-Tasks is a restriction which is not very useful at any time. As i am not able to use them in sprint planing, sub tasks getting more useles.

For handling our project it is needed to put subtasks with score into a sprint.

As you have plans to abonden the classic mode with next jira-agile release it is necessary to implement this feature before.

Any chance that this will be picked up in the near future?

Has anyone found a work around to allow this? As well as being able to see a Sub-Task on the Plan Board?

Any word on this? We need this ability too.... seems like most your users want this feature. If your not going to implement this what other systems do people suggest moving to?

As many people here, I'm creating issues and when it's required the issue is splitted into sub-tasks, asigned to different people. Then when I want to create sprint I want to choose which sub-task must be included and get time information about. Also to see the sub-tasks into the board columns.

This is very simple and quick way of working, with a few issue types and other concepts involved.

Also: Opening the option of using JIRA and JIRA AGILE in other bussiness than sw development, it's very good idea to be flexible and let the user take the decision. But not being limited by the product without any configuration option.

All of these are caused by the GHS-6825 which was closed two years ago as WontFix, people cannot vote on it or reopen it, is assigned to nobody and my guess is that Atlassian does not get/read any comments on closed issues, too much "spam".

Jeff is so right, we have an almost identical use case and we do have to spam the system with other issues that are in sub-tasks but we cannot use the sub-task because they do have any planning value as you cannot plan them separately.

In fact with the inability of scheduling/planing sub-tasks they are of no value, being better to make a list / table inside the ticket description and keeping them there.

I, too, would love this as an enhancement. I use Jira agile to manage sprints for an infrastructure team. Our stories have several sub tasks that we work on a few each week. Right now, I have to add the entire story and tell them the sub-set of sub-tasks to work on. Ugh.

we need it too!

I'm in full agreement with this requests. There are many use cases in our workflow

1) We have repeating tasks (User Stories) with repeating sub-tasks, so in order to avoid many task creation effort, we have task templates containing all the sub-tasks and just clone them. However, the tasks take more than one sprint to succeed and hence we need to be able to distribute the sub-tasks on more than one sprint. Notice that this is not possible by usage of Epics

2) Even in the case that all sub-tasks had been assigned to the same sprint, it may turn out that they weren't all finished in time. In that case it would be more transparent to just add the sub-tasks to the next sprint that remained still open.

3) Sometimes it turns out that a developer has some spare time at the end of a sprint and he may choose to finish a sub-task of a task that is likely to be in the next sprint. However, that work will stay unrecorded as the sub-task can't be added to the sprint. This is particularly often the case if you have specialized resources in your delivery team. Imagine you have 2 data specialists and a 2 program specialists. You have many tasks that require 1 of each type to succeed. As they are different people, you organize the task in two sub-tasks and assign one to a data specialist and one to a program specialist. Fine. Now one of the program specialist is on vacation. You end up with unmatched resources. You can work on the data side more than on the program side. However, you can't fulfill the User Story, because the program side will be lagging behind. Hence you would like to be able to add only the data sub-task to the sprint as you know from the beginning that the program sub-task will not be finished as it is not even assigned to anyone.

4) Last but not least: Not being able to add sub-tasks to sprints is against the intuition of every Jira user that I spoke to so far. It hence causes a lot of confusion and bad setups.

Please add!

I completely agree with Thilo! In our case we have sub-tasks assigned to different people - which are not visible on their boards.

Such a feature is also needed for an issue where the sub-tasks should be solved by different persons at different points in time. Without it the whole concept of sub-tasks is useless in an agile enviroment.

Need a bit of advise from JIRA Agile Gurus. We have been using Epics to represent large features taking months to develop, Story for features taking may be couple of weeks and Sub-tasks for smaller tasks with in a Story taking days to develop. Now since we can not plan with sub-tasks in a weekly sprint, does it mean we are out of line from using the Epic, Story and Sub-tasks in a right way or should we use larger duration sprints ... so basically what is the best practice here?

We are a Jira OnDemand customer, I don't think it's possible with this solution?

You might like to look at the Structure plugin from ALMWorks if you wish to aggregate tasks in a hierarchy in this way.

Thanks,
Shaun

Our Workflow for big tasks:

• Parent ticket for maintask with all informations (not placed in a sprint)
• Split the ticket in X subtask (4h till 2 days)
• Integrate the subtasks in X sprints (1-4 sprints)

Linking tickets is a workaround for us, but in many ticket filters, we will not display the subtasks and we will have the total estimate of the hole project visible in the main task, and this is only possible with subtask. right?

We have no plans to implement the ability for sub tasks to be in a sprint without their main task.

Could you provide some detail about why you want sub tasks in a sprint without their parent? In general a sub task is a technical task necessary to allow the parent story to be completed... the user deliverable value is the story itself, not the sub task.

You might wish to consider using full issues and issue links to link them together if your sub tasks are higher level than that.

Thanks,
Shaun