How to organize Structure without messing Jira boards?

[Martim Schnack]

We are using Structure to have a bird's eye view of everything that is going on with the company, departments, teams, etc...

We are creating items in Structure to organize the stories and tasks, bucketing them into groups. The problem is that each item in Structure is also a Jira issue. So if we create a item to organize all the things that we want to accomplish in the first quarter called "1st QTR", this will also create an issue that will appear in the Jira backlog.

Is there any way to create this "buckets" that serve only to organize things in a way that we don't also create things inside Jira boards?

Thanks!

[Boris Georgiev [Appfire] · Accepted solution]

Use different issue type for the "buckets" and then edit the board filter query to exclude them - i.e. type != Bucket (assuming that the issue type is named "Bucket")

[Robert Leitch [ALM Works]]

Hi Martim!

We create a special 'dummy' project in JIRA exclusively for these issues (we call them 'meta-issues'). That way you don't clutter any 'real' projects with them.

If you need to exclude them from any other lists of issues in JIRA, you can use a JQL query that excludes the dummy project.

Best, Robert

Edit: in Structure 3.0 we'll have native 'Structure issues' that will serve the same purpose without creating extra issues in JIRA.

Update: Structure 3.0 is now out and available on Marketplace.

It provides issue 'folders' amongst many other new features.

Please refer to the release notes for detailed instructions on migrating from 2.x

[Martim Schnack]

My concern with this approach is that each Structure will require a "meta-issue" project. If I create them as a different issue type, like suggested by Boris, it works without too much effort for all my Structures.

Any idea on when Structure 3.0 is going to be released? I can't wait!

[Robert Leitch [ALM Works]]

I'm not sure that you would need a separate meta-project for each structure? One should be enough for all your structures' meta-issue needs.

Boris' solution is also very good, my only reservations would be that it still leaves the question of cluttering the 'real' project with non-actionable issues that may, even if only slightly, skew project reports.

Giving the meta-project an easily identifiable key helps meta-issues to stand out from issue-issues. I often have a hard time identifying issue types at a distance.

Plus when filtering issues by a non-exclusive JQL query like project=a you don't need to exclude meta-issues from your results because they're not there.

Structure 3.0 - I can't be specific about dates I'm afraid, but yes, it's going to be pretty special. If you add me to Skype (r.leitch) or twitter (bobstwelve) I can get you signed up for updates :)

[Martim Schnack]

If I only have one meta-issue project, if I create another structure that also sees this project, all the meta-issues with also appear. But the categorization (or buckets) that I've created for project A should not appear in project B, C, etc..