Adding Features Between Epics and Stories

[Holly Scott]

I'm working for a rapidly growing company from small business to insane business and Jira has ultimately fallen on me. I want to add in Features, but will Jira maintain work item links even if the work type name changes from "Epic" to "Feature" at the Epic level? I'm not as concerned about anything higher in levels. @John Funk

[Paul Glantschnig _Appfire_ · Accepted solution]

Hi @Holly Scott ,

On renaming Epics to Features:

Yes, renaming the issue type preserves all existing links, parent relationships, and data. It's purely a display name change. However, be aware that level #1 in Jira's hierarchy (by default called "Epic") has special behaviour — it's how items appear in the backlog view, how the "Epic Link" / "Parent" field works, etc. So if you rename it to "Feature", everything still functions the same way, but it may confuse users who expect "Epic" semantics.

On adding a level between Epics and Stories:

This is the trickier part. Jira's built-in hierarchy only allows adding levels above Epics (requires Premium or Enterprise plan). You can't natively insert a level between Epics and Stories.

Common workarounds:

1. Rename levels: Rename Epic to "Feature" and add a new level above it (on Premium) called "Epic". This gives you Epic > Feature > Story, though the "Feature" level still behaves like Jira's level #1 under the hood.
2. Use issue links: Create a custom link type (e.g., "is feature of / has feature") and model the Feature-to-Story relationship through links rather than the built-in hierarchy. This is fully flexible and works on any plan, but Jira won't natively display this as a hierarchy in the backlog.
3. Labels or components: A simpler approach — tag Stories with a "Feature" label or component to group them, without adding a true hierarchy level.

Which approach works best depends on how you need to report on and navigate the hierarchy.

Just as food for thought — if you go the issue links route and want a way to actually visualise that hierarchy, my team and I work on JXL for Jira. It lets you define custom hierarchies based on issue links, so you'd see your Epic > Feature > Story structure in a table view with full nesting, regardless of how Jira's built-in hierarchy is configured.

Disclosure: I work for the team that builds JXL.

Best regards, Paul

[Holly Scott]

Thank you, Paul. This is very informative and will help me discuss these points with my superiors. Greatly appreciated! 

[Paul Glantschnig _Appfire_]

Following up with a visual on the JXL option I mentioned, @Holly Scott, since you mentioned discussing this with your superiors :)

In JXL for Jira, you set up a Custom Structure where each level in your hierarchy can be based on Jira's built-in parent/child relationships, issue link types, or a mix of both. So regardless of which approach you choose, you can get a full tree view like this:

Within this view you can inline-edit fields across all levels, and use sum-ups to roll up values like story points from stories to features to epics. This works on any Jira plan, no Premium required.

Cheers, Paul

[Olga Cheban _TitanApps_ · Accepted solution]

hi @Holly Scott !

Adding a Feature level between Epics and Stories is one of the most common requests in Jira - and unfortunately, it's not straightforward. Even on Premium, you can only add levels above Epic, not below.

That said, there's a practical workaround that gives you the extra level you need. Here's the idea:

1. Create a "Feature" work type at the same level as Story/Task/Bug
2. Use subtasks for what are currently your stories or tasks
3. Add checklists to those subtasks for granular steps - they will function as what are currently your subtasks

This way, your hierarchy becomes: Epic > Feature > Subtask (instead of Task) > Checklist items (instead of Subtasks) - that's four levels instead of three.

The checklist part can easily be done with our solution, Smart Checklist for Jira. It allows you to add a structured checklist to any work item in Jira. And these aren't just plain checkboxes. Your checklist can include:

• Custom statuses for each step - so it's clear what's in progress, in review, or done
• Deadlines and tagged team members - responsible people get notified and can view all items assigned to them on a dedicated tab
• Expandable details - add links, images, sub-steps, or any extra context in a collapsible field
• Rich formatting and headers - structure longer checklists into sections
  
  

So you're getting most of what a subtask offers, without the overhead of managing separate work items.

A few things that make checklists a useful tool:

• No board clutter. Everything stays inside the parent work item. Your board doesn't get flooded with dozens of extra tickets.
• Reusable templates. Save a checklist once and apply it automatically to new work items. Great for recurring processes like QA, onboarding, or release prep.
• Progress tracking at a glance. A progress bar shows how many items are done, and custom statuses show you step-by-step completion.
• Works on any Jira plan. No Premium required.

Hope this helps!

[Holly Scott]

This is a great suggestion as well, thank you!