Query the Whole Tree: How to Manage Complex Jira Projects with JQL That Keeps Itself Up to Date
Every complex Jira project eventually turns into a tree. Initiatives break down into Epics, Epics into Stories, Stories into Sub-tasks. On top of that come links: dependencies, blockers, work shared across teams and projects.
Jira is great at showing you that structure, one issue at a time. Open an Epic and you see its children. Open a Sub-task and you see its parent.
But try to search that structure, and you quickly hit the limits of native JQL.
The problem: static lists in a moving project
Say you want every Story under the Epics that are currently In Progress. Native JQL only offers parent = ACEO-1: one key, one parent. With 40 active Epics, you end up maintaining a long list of keys by hand.
That works until it doesn't. A new Epic starts, another one closes or moves to a different release, and your filter is already wrong. Usually nobody notices until a dashboard shows the wrong numbers in a status meeting.
On complex projects, a static list is out of date almost as soon as you save it. What you need is a query that describes which parents you mean, not which keys they have today.
childrenOf: down the tree
Argon's childrenOf takes a JQL query instead of an issue key. It finds the issues that match, then returns their children.
- issue in childrenOf("project = JAI and issuetype = Story")
That's every child of every active Epic, in one search. When a new Epic moves to In Progress, its children appear automatically. Nothing to update.
parentOf: up the tree
parentOf works in the opposite direction. You describe the children, and it returns their parents.
- issue in parentOf("project = JAI and issuetype = Sub-task")
This is the view a team lead usually wants: not 200 Sub-tasks, but the 12 Stories that have a problem inside them. Swap "Blocked" for overdue or unassigned work, and you get the same kind of shortlist.
It also works with not in. Ask for Stories that have no open Sub-tasks left, and you get a list of Stories that are probably ready to close.
Hierarchy is only part of the picture
Parent–child relationships show how work is broken down. But on complex projects, three other questions come up just as often:
- What depends on what?
- Where is work getting stuck?
- Who changed what, and when?
Argon has functions for each of them. They all work the same way: a JQL query in, a live list of issues out.
Dependencies: linksQuery and linkedByQuery
Issue links are where cross-team dependencies live. linksQuery follows outgoing links from the issues you describe, and linkedByQuery follows incoming ones.
Bottlenecks: timeInStatus
A tree can look healthy on a board and still hide work that hasn't moved for weeks. timeInStatus finds issues by how long they've spent in a status, and it combines nicely with hierarchy.
Change history: transitionedBy and changedBy
On big projects, "what happened?" matters as much as "what's the status?". transitionedBy finds issues moved to a status in a given time window, optionally by a specific person. changedBy does the same for field changes, such as a priority that moved mid-sprint.
Why it matters
Complex projects rarely suffer from too little data. They suffer from data that's out of date or spread across ten different screens.
Making hierarchy, links and history searchable changes that. The questions a project manager asks every week ("what's blocked?", "what's stuck?", "what's left in this release?") become saved searches instead of manual work.
You can check and try JQL Argon app on Atlassian Marketplace: JQL Argon Powerful Search
Enjoy!
Orbiscend Team
(JQL Argon app provider)
