Hi 2c86a546f0e5, it's something we want to build and it remains in the longer term backlog, but there are no immediate plans to work on this. The investment required is unexpectedly high and to date other initiatives have been prioritised above this https://www.atlassian.com/roadmap/cloud?selectedProduct=jsw&. I apologise for the frustration and inconvenience this has caused.
Regards, Eoin

2c86a546f0e5 +1 on all that you wrote. 

So this has been known and tracked since 2019 and still not fixed - come on Atlassian!!
From my own experience working with software, I'd say we've all spend much much more time talking about this problem (and it's drawbacks) than Atlassian have spend on actually fixing it.  

I find it hard to believe it's immensely difficult to find and display the subtasks connected to parent issuetypes with a certain sprint assigned to it during various lookups, even though the subtasks themselves lack the sprint information directly. 
Hint: look on how you implemented 'Group by - Subtasks' in TMP sprint board - all subtasks are found just fine there.     

eryan / anyone,

• is there any update on this please? It's blocking a High Priority Bug JSWCLOUD-26933 (and now JSWCLOUD-26207)
• Scrum board not functioning as expected rendering it unusable for our team.

Could you help answer as well, looking at the History:

• why was this not a bug any more?  but flipped to "Suggestion" from a "Bug" in year 2022.
• why was this priority lowered from High in year 2022. (when this bug / same issue was tracked from 2019)

Hi team. Any update on this?

Hi eryan.  What's the priority of this issue? It blocks JSWCLOUD-26933 which is an inconsistent behavior with Kanban board. This ticket is definitely a bug and not a suggestion.
We just switched from Kanban to Sprints and I noticed this significant inconvenience. We have been using sub-tasks a lot while in Kanban since they were showing there just fine.
More of my issue is described here 

Hector, this used to be a Bug. They reclassified it at one point, which met with objections here. Still no solution. This has been on the books for years—since they introduced the new project format (and renamed it multiple times).

Please note that this (JRACLOUD-81069) is not really a suggestion - it's an important missing feature. I would rather classify it as a bug since filtering by Sprint does show Subtasks when in a company-managed project - same filtering user interface, different project type. Unless that was done by design trying to produce a lighter version of the company-managed project type in the team-managed project type.

A consequence of this issue is that even though a recommended practice is to break user stories (deliverable) into subtasks (means to deliver a story), managers refuse to use subtasks because they can’t report on them. So, instead, they recur to use Epics as User Stories, and issues of type Task as subtasks, but that creates a distorted backlog size, and the concept of Epic gets distorted too.

For example, if the backlog could have been 10 user stories, it becomes a much larger size if those 10 stories are broken into issues of type Task, thus making the backlog look much larger to leadership.

https://getsupport.atlassian.com/browse/JST-955717

Please solve this. It's a hindrance to reporting work. I should be able to write the following JQL and have it work.

issuetype = Subtask AND sprint in futureSprints()

I got a workaround and that works for me.

• Create 2 automation rules for all subtasks to fill the sprint name in the subtask's label:
  • When: Issue created, Condition: Issue Type equals Subtask, Then Edit issue fields Labels = 

    {{sprint.name}}

• • When: Value changes for Sprint, For: Sub-tasks, Then: Edit issues fields Labels = 

    {{sprint.name}}

• Then create a filter to query all the Subtasks have label that match with your sprint name: 

  project = XYZ AND issuetype = Subtask AND Labels in ("Sprint.ABC")

Note that:

• Your sprint name should not contain space character as the rule of label does not allow space
• Currently I'm not found the way how to automatically get the sprint name in the opensprints(), so everytime you change to a new sprint, you need to manually update your query with new sprint name.

is there any update about this? please fix it asap

I feel upset, really.

Currently I have to query thousand of issues per time instead of les than 200 due to this bug.

We want to assure you that we are taking your feedback seriously. Please know that this reclassification does not diminish the significance of the problem or how we plan to address it. Rather, the type change reflects alignment on internal processes that can influence the prioritization of code changes and is intended to benefit our users.

Why did this go back to being a suggestion? This is not a suggestion—it's a bug. Your query engine is incapable of delivering the expected results here. This is a necessary function to manage work being done in a sprint! I had to stop using Jira because you can't support this basic task-management capability.

The bug is impacting our ability to do reporting in the dashboards accurately.  We are unable to see the whole picture of time spent from our users in prior sprints and do not have a viable workaround in place to do the measurement.

In case it helps, I'm using this JQL to search all open tickets in current sprint including subtasks:

status in ("In Progress", "To Do") AND (Sprint in openSprints() OR type=Subtask)

Team,

Currently we are being impacted at a higher level. It is a tedious job for Scrum Masters to review the sub-tasks especially during Daily Stand Up calls. 

Please provide an alternative or a fix to this issue ASAP, Indeed this is making things worsen such as heading back to Excel.

Regards,

Ashok Kumar.

Please work on getting this resolved

Please solve this.

Please resolve this soon! Must be a bug and should not be too difficult to fix. 

I tested this function, and it is convenient that choose some sprint, but I couldn't see subtasks in choosing a sprint! Summary:

I can easy find some sprints. But cant see subtasks in sprints  

My workaround for this stupid defect: 

• create a custom field in sub-task
• create an automation to update the field (if the story in current open sprint)
• run the automation to update the field
• use the field for filtering out the subtask

Agreed - would like to see this functionality!

Looks like a bug to me. Can this be resolved please? 

Please resolve this. It's very basic! we need to filter Sprint subtasks! 

@MarkZ,

How many votes are needed to prioritize this issue? I work with a process that leverages subtasks heavily for our developers. It would be great to be able to search by subtasks for a particular Sprint and group by asignee. This would help me to run my daily status calls more efficiently. Thank you.

Hi everyone,

We want to give you an update on this matter. We cannot address the issue of missing functionality in the next six months, as it will require bigger changes to our architecture.

We have thus converted this bug to a suggestion ticket so that you can upvote and track our progress.

Product feedback is collected from many different sources and is evaluated when planning the product roadmap. You can learn more about our process here.

We apologise for this inconvenience and thank you for your patience.

Great to see atleast some movement in the status of this ticket. I can see the issue is in Gathering Interest stage - does this mean Jira is waiting for more interest and votes before working on this? This is a serious bug. We have 144 votes on this issue and its unresolved for 3 years! I think it deserves a lot more focus and priority.

How does this even not solve yet as of now?

Plugin Paid version is tremendous set back. this feature should be within the capability of team Jira.

I feel dumb every time I need to re-elaborate to my team why we can't do simple thing like this with Jira

The workaround to this problem that i found, that work for me, is:

• Create a custom field in the subtask in where you will store the id of the active sprint.
• Create an automation that when the subtask is mark as DONE you will trigger. Here you will assign the ID of the active sprint to the custom field that you created previously, with the next code (customfield_10020 in my case is the field of the active sprint): 

{{#issue.fields.customfield_10020}}{{#if(equals(state, "active"))}}{{id}}{{/}}{{/}} 

• Finally in the JQL, you will search for the subtask with the custom field with the sprint ID equal to the ID of the sprint you want to filter.
  I used this in JQL (I named the custom field "Done in Sprint"):

  "Done in Sprint[Number]" = 4  

  And this for find the done task in the current active sprint:

  "Done in Sprint[Number]" in openSprints() 

You could change the trigger for differents purpose, like when its created or when its moved to "TO DO"

I hope this will help you to workaround this problem.

It's curious that this is solvable with a (paid) extension but not something that can be baked into JQL. Searching sub-tasks would be a godsend.

Hi all, a reminder to our existing and potential users: if you have a strong requirement for this feature to work today, you can use our paid app JQL Search Extensions.

This a query that you can use to get all issues in the sprint with their subtasks:
sprint = "sprint" OR issue in subtasksOfParentsInQuery("sprint = 'Sprint 1'")

Feel free to contact us for more information and help.

Hi everyone,

Unfortunately, after exploring several options, we cannot provide a fix in the short term.

Calculating the subtasks of a Sprint to show to the customers of team-managed projects (formerly known as Nextgen) is a complex operation, especially across Jira instances where there are many issues. 

In the previous attempt, the optimisation was not enough to fix the problem. We are now exploring architectural solutions for searching via Jira Query Language (JQL). We firmly believe this will fix the problem and deliver faster searches across Jira, but it will take time to identify and implement the right solution. 

We know this isn't what you were hoping to hear, and we apologise for this inconvenience! We are doing our best to resolve this, and once we know how to fix this, we will share an update here. In the meantime, if you have any questions, please let us know.

Thank you for being so patient!

If I individually move the subtasks (go through the move process, but move them to their currently assigned parent issues) this seems to fix the problem with them appearing in the query.  It is a lot of work of course, if you have multiple sub-tasks.

Hi everyone,

We want to share an update on this issue. Some of our customers could not load their board due to timeouts, so we had to roll back. We have now identified a potential fix and need to work with internal teams to plan when we can roll it out. We are doing our best to get this done, and we appreciate your patience!

Hi all,

Unfortunately we have to roll back the fix because the latest change has caused some problems with a subset of customers.

We will keep you updated on our next step.

Thanks!

Hi all,

Thanks for the wait. We have rolled out the fix into production now. If you search for issues in a Sprint it will now include subtasks.

If there are any problems please raise a new ticket. Thank you!

I've also updated the ticket to be in the short-term status with a high priority to avoid any confusion.

Sorry everyone for the wait.

Just a quick update on this ticket. We have implemented a fix and are assessing the impact on other parts of Jira that share the same functionality to ensure that there are no regression. Thanks again for your patience.

The priority of this ticket is still marked Medium. Not sure how are you saying it is high priority!

You can at least map the parent to the Key instead of the Summary. This would be a workaround for now.

How is it that this basic bug has been here for almost 3 years and it's only now becoming a "high priority".

Hello everyone,

As mentioned by peterwong.au, we have made this ticket a high priority in our backlog. We have started an investigation into this problem and have found a potential solution, but we need to do further testing before we can confirm this solution. We will keep you up to date on the progress shortly. Stay tuned, and thanks for your patience!

Peter Wong: Thanks for your feedback. It's encouraging to read that you hear our callouts. On the other hand, this issue is still on the "Long Term Backlog" - which is anything but encouraging. We're now considering following Michael's example, to switch to another solution (such as ClickUp).

I just switched to ClickUp and it solves this and most my other problems with JIRA. Sorry guys, but 3 years in the backlog was too long. Good luck!

To our customers affected by this bug, we have heard your callouts for the past few months. They have not gone unnoticed.

We apologise for the issues these have caused.

We have been reprioritising our efforts, so that our team is able to renew some investigations into this long-standing issue, to find the best way forward to resolve this issue. We will soon provide an update on these investigations and our next steps

Thank you for your patience,

Peter Wong
Team Lead | Jira Software

This results in a custom board (pulling in team-managed project issues) with swimlanes of "Story" - don not show the subtasks. 

I hope either this thing is fixed or proper swimlanes functionality is added to team-managed project

Daniel, it is nice that you have this covered in your proprietary paid app. But this is such a basic functionality, that it should be supported by JQL out of the box. Jira and JQL isn't supposed to be crippleware. Even the most basic subscriptions are expensive, and one should expect most typical and basic needs to be coved with the most basic subscriptions. But, as it stands, Jira can indeed be interpreted as crippleware - especially with regards to JQL. 

Hi all, if you have a strong requirement for this feature to work today, you can use our paid app JQL Search Extensions.

This a query that you can use to get all issues in the sprint with their subtasks:
sprint = "sprint" OR issue in subtasksOfParentsInQuery("sprint = 'Sprint 1'")

Feel free to contact us for more information and help.

Can this please be fixed, this surely should be out of the box functionality.

What is the point of Dashboard functionality when  you cannot search/filter on the most basic items within a sprint.

Seriously why is this not basic functionality?

It is very painful when I'm trying to estimate the amount of work in active sprint for the dev team with no any single sub-task in report. Shame that priority for such basic feature is LOW . Also I'm very confused why is the lack of such basic feature is "not as severe or pervasive as other issues" (see current issue status description). Yeah, it's way more "severe" to swap navigation experience twice a year... I miss Redmine so much...

I agree that this should be much higher than "low" priority...

Commenting to keep this leveled up. Please address this

I think it's a minor effort enhancement but takes big benefit to Project Management in Jira tool. Please consider it with higher priority.