Meta-issues in Structure

A meta-issue is an ordinary JIRA issue that is created and used solely for 'structural' use in a Structure hierarchy. Much like an Epic in JIRA Agile, it does not represent a task in itself; it is not something that you would log time against.

Meta-issues 'contain' other issues in a structure hierarchy branch, i.e. other issues are placed underneath them. These could be issues belonging to a particular team or department, or just any collection of issues we want to group together.

This allows us to do much more than just collect and organize issues to make them easier to find and work with. It also allows us to get aggregated values of all the issues' numerical fields and progress rolled up into the meta-issue that contains them (and beyond).

Meta-issues with aggregated progress and story points. Gray highlights and arrows added for illustration

This is very useful, for example, when tracking progress of JIRA Agile projects. It also makes it easy to drill down into a structured hierarchy of issues to inspect progress and other aggregated information at different levels.

Meta-projects for meta-issues

There are many ways to demarcate issues as meta-issues. You could use a label, a special issue type or component, a custom field or feel free to add more ideas in the comments below.

At ALM Works, our standard practice is to create our meta-issues in a 'meta-project'. This keeps our real projects free from meta-pollution. We can write JQL queries like project = "Chicago" without having to specify additionally that meta-issues should not be matched.

However you choose to distinguish meta-issues from 'ordinary' issues, there are other benefits to be had in doing so. Using Structure's search and filter functionality, we can hide the 'actionable' issues, leaving only the meta-issues visible.

Structure filtered to show only meta-issues

The filter removes as many non-matching issues from the board as possible, and greys out any non-matching issues that can't be removed (for example, because they are part of the hierarchical path to a matching issue). The result, illustrated above, is a very streamlined and report-like structure that shows us the progress and aggregate values of key issue groups.

Why you soon won't need them at all

Structure is evolving, and a major new version is in the pipeline. This will be a fundamentally revised Structure (internal codename: Structure 2G) with many new features and new ways of working with JIRA issues.

Structure 2G will come with its own native 'meta-issues'. These will behave in Structure in much the same way as JIRA issues do, but will not be seen in JIRA. Of course, your existing structures with their JIRA meta-issues will still work; the new version of Structure simply adds the option of a native feature to replace this technique.