Why can't I find a subtask with the issue key????????????

I am wildly frustrated with the way subtasks, once created, are so very hidden in JIRA.  

I had a note for myself from last Friday: "SE-106".  Typing in this very issue key into the searchbar returns no results.  

By and by, after clicking around endlessly and wasting time, I found it: SE-106.  A subtask of SE-11.  I hadn't been mistaken about the issue key.  It is just that it doesn't come up in the search.  I checked, and if I perform the exact same search, but with the issue key of a regular task, it does work.

Now, first of all, I shouldn't have to keep separate notes about which precise issue keys I need because subtasks are so darn hard to find.  But even if subtasks ARE buried and hidden to the point where I am tempted to stop using them (which is a shame, because my brain works best with tasks and subtasks) I would really like to know:

Am I doing something wrong here?  Or is it true that you can search for regular issues by key, but issue keys aren't enough to find subtasks????  I shouldn't have to write a JQL query to find a task when I have the exact key.  If that is the case, that is absolutely foul.  

1 answer

1 accepted

1 vote
Accepted answer

Nope, SE-106 absolutely should find you the sub-task and jump you straight to it when you use it in the quick-search.

I'd say there's something wrong with your index and reach for the logs, but as you're on Cloud, you'll need to throw that over to Atlassian support to do the investigation for you.

To clarify, Katie was entering this issue key into the Instant Filter at the top of the Backlog.


Ahh, where subtasks aren't displayed.

Eventually, we sorted that out.  But wouldn't it be glorious if you COULD access subtasks from that search...looks like they're working on it.

I'm not sure, as the subtasks aren't needed in that view.  But if it told you it's a subtask and offered to take you to it on the board or the main view, or (probably best), the parent issue, I'd appreciate that.

I personally think subtasks are needed in that view...not on the same level as the other tasks, but visible if you want them to be.  I guess everyone uses JIRA differently.

I don't think they are.  You can't rank them outside the parent (it's logical nonsense, or, when it's not, it's a clear indication that you're breaking up your stories incorrectly), so there's not a lot of use for them in that view.

Not to rank them.  Simply to see that they exist.  If you're looking at several closely related issues in your backlog and wondering, "did I make a task or subtask for that little thing that came up?  If so, where did I put it?" it would be nice to see which issues have subtasks and which don't.  I know that you can search your issues, but I prefer the backlog view.  As I said, different users have different needs for JIRA...there's more than one way to do things, as evidenced by the many options for preferences and customization that are already built in.  Perhaps your way adheres more closely to agile rules, but our team is using a looser adaptation.

Mmm, I'd just find it even more cluttering.  But I do like the search jumping you to the parent idea, so you can go look at it easily.

I guess to clarify, I wasn't thinking that they would be right in there among all the other tasks.  This was my subtask vision:

  • Subtasks in the backlog would be a feature one would choose to enable...without it, the backlog would remain the same.
  • When enabled, you would go to the backlog, and it would look mostly the same as it does now: only regular tasks would be listed.  But, let's say on the right end of each task, imagining you nudged that grey time estimate oval and everything else there about a half inch to the left, there would be a little brightly colored icon with the number of subtasks, and a down-pointing chevron.  (If the issue had no subtasks, there might be a grayed out zero there, and the chevron would look disabled, just something very faint and unobtrusive so it would be clear there were no subtasks, but also it would be good to keep something there so the alignment of the other items like the time estimate wouldn't get shifted over)
  • If you click the down chevron, it toggles a drawer opening downward: all subtasks would show up under the parent task.  They would be indented to the right a bit, possibly with a faint grey background or something, to clearly differentiate them from regular tasks.  You'd be able to click the issue key, see who is assigned, and so forth, very similar to regular tasks, BUT you wouldn't be able to move them independently.  If you drag the parent task (or, really, anywhere on the whole thing except that little chevron or the links) it and the subtasks move as a unit.
  • That would probably be the primary way I'd use them: see which tasks have subtasks at a glance by the icons, click on an individual task, see its subtasks.  But at the top of the backlog, there would be buttons so you could toggle them all open and all closed.  All open would be a LOT, and you'd probably only use it for a few minutes if you were just scanning through to try to find something.  That's why you'd want to close them all with another single click.  
  • Open subtask lists would stay open either until you clicked the chevron to toggle them closed, or until the page refreshes.
  • On a subtask search in the backlog, it would return the parent task with its subtask list open, so you could see it there, possibly highlighting or pointing to the one you searched for.


I can see the way you're thinking here, but I think it's elevated sub-tasks way above their real value as JIRA Software stands.

The Backlog view is for ranking your backlog and selecting what needs to go into the next sprint.  Sub-tasks, while immensely useful as ways of breaking down work, granting multiple assignees, giving you granular reports, and allowing for different processes, do not have anything useful to say about ranking and sprints.

Your suggestions make a lot of sense, they're clean, simple, intuitive and clear.  I really like them, especially as they lend clarity without trying to break the basics.  Most people who ask for subtasks in the backlog are trying to do something illogical which would guarantee a failure in their planning or project.  You are not one of them.

But, it's not needed.  We rank the stories, we plan them.  The sub-tasks aren't needed for that.  If they appear to be needed, then they're probably stories in their own right.  I think Atlassian are moving towards some more visibility of sub-tasks, but for the vast majority of their user-base (including me), sub-tasks are not needed when planning a sprint.  Yet.

IF Atlassian ever deal with the "estimate at sub-task level" problem they have, then sub-task visibility on the backlog might become useful.  But until that happens, I don't think we'll get anything (and I can't see a use for it until those estimates start to matter). 

But, IF they ever go that way, then I'd want to use your spec as a starting point.


Suggest an answer

Log in or Sign up to answer
Community showcase
Published Nov 27, 2018 in Portfolio for Jira

Introducing a new planning experience in Portfolio for Jira (Server/DC)

In the past, Portfolio for Jira required a high degree of detail–foresight that was unrealistic for many businesses to   have–in   order to produce a reliable long-term roadmap. We're tur...

2,672 views 18 21
Read article

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you