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.
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.
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.
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:
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.
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!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
We're bringing product updates and pro tips on teamwork to ten cities around the world.Save your spot