Defining a JIRA Agile team backlog requires some means of linking issues to teams so that you can fetch the backlog with a JQL query. There is no JIRA team field, and you can't assign an issue to a group either.

Typical solutions include using labels, adding a custom team field or writing queries that look for issues assigned to anyone in a list of all the users in the team. These methods work fine for relatively small projects, but for large organizations with many teams working on large projects they are cumbersome to maintain and can lead to issues becoming 'lost' or overlooked.

Structure to the rescue

There is no standard mechanism to assign a JIRA issue to a group or a team, but there's a very easy way to achieve a similar effect using the Structure plugin from ALM Works. It doesn't involve any custom issue fields or bulky queries and it's easy to set up. Using this method, issues are 'assigned' to teams with minimal effort using Structure's drag and drop interface. Here's how it works:

One structure per team backlog

We already know that Structure is very good at containing arbitrary collections of issues. It also extends JIRA's JQL with its own structure() function that can search for issues within a specified structure and constrain results based on the position of issues in the structure hierarchy.

This means that we can throw all sorts of otherwise unrelated issues (in this case, our team's backlog) into a structure and then retrieve them from anywhere that JQL is accepted.

The simple query issue in structure("structure name") will fetch all the issues from the specified structure. A query like this can be used as a board filter in JIRA Agile to return all the issues contained in a structure named, for example, 'Team A'. Other teams can be equipped with their own backlogs in the same manner.

Giving your saved filters really long names is optional

This is a good demonstration of how Structure can be used to group and categorize JIRA issues, but it will be a little primitive for most backlog purposes as it does not prevent issues from being present in more than one team backlog at the same time. Don't panic though, there's an easy solution for that.

With a slight modification to our approach we can ensure that each issue only appears in one team's backlog. It also enables quick identification of any issues that have not been assigned to a team and generally makes everything easy to manage.

One structure for all team backlogs

To ensure that each issue appears only in one team's backlog, we can take advantage of the fact that Structure does not allow issues to be added to the same structure more than once. In this method we keep all our teams' backlogs in a single structure, with each team's issues (backlog) arranged under a placeholder 'meta-issue'. We need to adapt our JQL query accordingly.

The structure() function takes an optional second argument that constrains results based on relationships between issues and their positions in the structure hierarchy. The second argument is written using a language we call Structured JQL, or S-JQL for short.

We want to retrieve all the sub-issues of the issue that contains our team backlog. The S-JQL part of the query for this is simply "descendant of issueKey", so the whole query to retrieve one team backlog from our structure will look something like this:

This will return all issues contained under the issue with key 'MTS-1':

Targeting contents of a specified Structure node with S-JQL

Note: The descendant of relationship constraint matches all sub-issues of the specified issue, which in our example returns the entire backlog. There are many more relations in S-JQL that can be used to constrain results. For example, if we use child in the above query instead of descendant, it will match only the top level of issues in the team backlog.

Managing multiple team backlogs in one structure

Assigning issues to teams in this structure is a simple matter of dragging and dropping them into the team's 'backlog' meta-issue. But first we need to get those issues into the structure board.

One way to get issues into a structure is by using search. A plain JQL query like project = "project name" will match the issues that we need to assign to our teams. If the query matches issues that are not already in our current Structure board, we will see a button informing us how many more issues were found in JIRA. Clicking it opens the search results panel, from which we can drag issues into the structure board and into our team backlogs.

Plenty more issues in JIRA

Any issues not already in the structure will appear in the search results panel, where they can easily be seen at a glance. Search results panel empty? Good, all our issues are assigned to teams. We need to refresh the page to check for new unassigned issues though, as the search results panel does not update dynamically.

Using perspectives, we can create a link to this exact search state that will not persist to other structures opened in the same browser.

Another way to get issues into a structure is to use an automatic filter synchronizer. The synchronizer should be set up to pull in issues that match the filter into the structure board and place them under a separate container issue for unassigned issues, from where they are subsequently distributed manually among our teams' backlogs.

By the power of S-JQL

This approach can be applied to much more than just team backlogs; a structure with some meta-issues is all you need to enable the same kind of drag-and-drop assignment of JIRA issues to 'virtual' categories that can be queried from anywhere JQL is used.

While we're on the subject of S-JQL, it's worth mentioning that the examples here barely scratch the surface of what it can do. There's so much more fun to be had with S-JQL that I'm quite sure there will be a future blog post dedicated to it. In the meantime, there are plenty of practical examples in the S-JQL cookbook to whet your appetite.

Want to try something out but don't have your own Structure yet? Feel free to play with our demo Structure, where you can safely mess things up us much as you like.