Improve your Jira structure with an epic>story>task hierarchy

By default, Jira supports an issue type hierarchy of epic>story>sub-task. The problem with this is that you can't add sub-tasks to sprints like you can with stories, tasks, bugs, and other base layer issue types.

Without sprints, you lose access to a range of built-in reports designed to help manage your projects. Jira provides burndown charts, burnup charts, sprint reports, velocity charts, and version reports, many of which require sprints for data. Although some teams may not need to batch their work into sprints, for others this functionality loss is a deal-breaker. 

To overcome this and access Jira’s built-in reports when using this hierarchy type, teams can still use sprints and simply add higher-level stories instead of lower-level sub-tasks. This works well if stories are small and only contain two or three sub-tasks.

However, for teams with large stories and many sub-tasks, work may not fit into a single sprint. Even if it does, Jira’s built-in reports won’t be as useful. Rather than being updated whenever a sub-task is resolved, the report will only update when the entire story is complete, making reports patchy and inconsistent, tracking less accurate, and forecasts less valuable.

Taking another approach with your hierarchy, you could use Jira cloud Premium and create levels above epics, leading to a feature>epic>story hierarchy.

With this issue hierarchy, everything moves up a level. What would’ve been a story is now an epic and what would’ve been an epic is now a feature. Since stories are now the lowest-level issue type, all work can be added to sprints, and you can use Jira’s built-in reports to track your project accurately.

So what’s the problem? The first limitation is that Jira cloud Premium costs US$10 per user. This can be a steep price to pay to use a more comprehensive issue hierarchy. 

The second limitation is that you can’t add epics to sprints. This means you must break down every epic into stories—but some epics might not need to be broken down further. This creates extra work, which can be confusing as well as inconvenient.

An epic>story>task (or epic>story>task>sub-task) hierarchy has two levels which can be added to sprints: stories and tasks.

This gives you the flexibility to add stories directly to sprints, or further break down stories into several tasks to add to sprints.

With this approach, you don’t need to:

• Add overly large stories to sprints
• Try to use epics as your middle level
• Pay $10 per user for Jira cloud Premium

Plus, you’ll get to:

• Add two different levels (stories and tasks) to sprints
• Use all of Jira’s built-in reports
• Sidestep the hassle of using epics as stories

This can work for many teams without an external add-on.

Adding a task to a story under the epic>story>task hierarchy can be fiddly. One way is to use issues to link a task to a story natively in Jira; however, Jira won’t know you’re trying to create a hierarchy.

A simpler way is by using an add-on. Hierarchy for Jira lets you create a completely custom issue hierarchy, so you can create levels both above epics and below stories. This makes it easy to create an epic>story>task>sub-task hierarchy and easily link task to stories (or any issues to each other in a parent-child relationship). With this method, you retain the use of Jira’s built-in reports AND you get a handy tree view of your Jira issue hierarchy.