Swimlanes Feature Level

[Haya Bawati]

Hi everyone,

I wanted to ask if it’s currently possible to display swimlanes on a board by feature.

I’ve already tried configuring swimlanes using JQL queries, but I was wondering if there are any newer or improved methods available to achieve this more effectively.

If anyone has experience with this or knows of alternative approaches, I’d really appreciate your insights.

Thanks in advance! 🙌

[Trudy Claspill · Accepted solution]

Hello @Haya Bawati 

Welcome to the Atlassian community.

When you say Feature level do you mean that you have modified the Work Type hierarchy to add a level for Feature types above Epics?

If so, then the only native method for creating Swimlanes in a board based on such a level is to use JQL queries to explicitly define a swimlane for each Feature. You can use he portfolioChildIssuesOf() function to get the child work items for a specific feature.

https://support.atlassian.com/jira-software-cloud/docs/search-for-advanced-roadmaps-custom-fields-in-jql/#Child-work-items

[Haya Bawati]

Hi @Trudy Claspill

Thanks for your reply! 

To clarify, by "Feature" I mean a standard issue type, not a hierarchy level above Epics in advanced Roadmaps. 

I was checking whether there's any newer or alternative way (beyond JQL-based swimlanes) to group issues by Feature on a board. 

Appreciate the confirmation and guidance!

[Joshua Brock _ Seibert Group_ GmbH · Accepted solution]

Hi @Haya Bawati ... welcome!

 
Just to add another $.02...

To answer directly: JQL-based swimlanes (using portfolioChildIssuesOf()) are still the standard native method for grouping by Feature on a Jira board, and there's no built-in "group by parent issue type" option in the board configuration. The JQL route works, but as you've found, it means maintaining a separate query for each Feature, which becomes a maintenance burden as your backlog grows.

The underlying reason this is awkward natively is that Jira's board model is optimized for sprint-level work. Feature-level grouping is really asking for a hierarchy view (stories sitting under their parent Features) which is a planning construct more than a day-to-day tracking one.

If your team is using a Feature→Story hierarchy intentionally — for example, as part of a scaled agile or SAFe setup across multiple squads — that's where the approach changes. Agile Hive enforces the SAFe issue hierarchy (Portfolio Epic → Feature → Story) as a native data model inside Jira.

Feature-level visibility isn't a JQL workaround there; it's built into how work is structured and tracked. Cross-team dependencies at the Feature level also surface in a dedicated board rather than being inferred from issue links.

That said, if you're on a single team and just need cleaner swimlanes for an existing custom "Feature" type, the portfolioChildIssuesOf() JQL approach or JXL for Jira (as Paul noted above) are practical short-term solutions.

If your team is heading toward Scaled Agile, Agile Hive is worth exploring. We extend a free trial available on the Atlassian Marketplace.

 

And just in full disclosure, I work at Seibert Group GmbH, the team behind Agile Hive.

Hope this helps!

Joshua
Content Writer & US Representative
Agile Hive and Aura Apps (products of Seibert Group GmbH)

[Paul Glantschnig _Appfire_ · Accepted solution]

Hello @Haya Bawati, and welcome to the community!

On a Jira board, the JQL-swimlane route (one query per feature, using portfolioChildIssuesOf()) is really the only native way to get feature-level lanes, and it does mean maintaining a separate query for each feature.

If you're open to an app from the Atlassian Marketplace, JXL for Jira offers a different angle. It's a spreadsheet/table view where you can build a hierarchy or grouping by any field, including the parent Feature, so your stories and sub-tasks sit under their Feature automatically. New features and child items just appear in the right place, with no per-feature query to maintain.

It's a table rather than a draggable board, so it won't replace the board's drag-and-drop columns. But for organizing and reviewing work by Feature, with optional sum-ups (story points, time, counts) per Feature, it's a low-maintenance alternative.

Disclosure: I work on the JXL team.

All the best, Paul