The Tip of the Month, brought to you by Atlassian University, is a monthly series
to help master Atlassian tools. Products are more fun to use when you
know all the tricks.
Understanding Filtering in GreenHopper and Jira
Sometimes we need to bring out our inner nerd to solve problems. Sound cool? Then this tip of the month is for you! GreenHopper allows you to organize issues in your agile development program in an Agile board. Let’s take a minute to see how Jira and GreenHopper focus issues in an Agile board to help you manage your projects more efficiently. In most organizations, Jira is used by many teams. A Jira project contains all of the issues for a specific program into one place. A board in GreenHopper can pull issues from one project or many projects into a single, agile optimized view. With Quick Filters, you can go one step further and focus in on a subset of issues that are on your Agile board.
Why would you want to do this? Sometimes you need to focus on a subset of the issues at hand and answer questions like:
- What issues are open for me in this sprint?
- Which issues are the server team involved in?
- How many issues have the customer reported label?
Understanding Quick Filters
Quick Filters allow you (or anyone else using this board) to further filter the collection of issues appearing in Work mode or Plan mode. By default, a board contains two Quick Filters, called ‘Only My Issues‘ and ‘Recently Updated‘. Quick Filters are JQL queries. If you’ve not used JQL before, check out our JQL series on atlassianblog.wpengine.com. For example, one of the default Quick Filters in every board is Only My Issues. The JQL is simply:
[cc lang=’sql’ ]assignee = currentUser()[/cc]
Thus enabling that Quick Filter only shows me issues that are assigned to me in the board. Quick Filters are also additive. In the below example, the board will only show my issues that have been recently updated.
Scaling Quick Filters
In many organizations teams work cross functionally. For example, UI teams often work across a number of product teams lending out their expertise. The UI teams need a way to see what issues they need to work on. Each product team needs to see which issues depend on the UI teams. How can we get the best of both worlds? We define a Quick Filter as a filter!
The UI team has a convention of using labels to track issues that require UI work in all the product teams. It’s easy to find these issues in the issue navigator:
Note that we’re not adding other criterion as we want to see all the issues that involve the UI team. Clicking the Save As button will save that search as a filter. By default, filters are private. I can only see filters I create. We want everyone to be able to see this filter so click Edit Permissions and add everyone to the filter shares. I’ll explain why in a few sentences.
Here is where things get interesting. Let’s say your organization has three different teams in it that interact with the UI team. Each team will have it’s own board that shows that team’s work. We can create a common Quick Filter that highlights their tickets that involve the UI Team.
Since Quick Filters are a secondary filter, this quick filter will only show issues involving the UI team on that board. So why not just use the query labels in (ui)? If you use a named filter any changes to that filter propagate to all the boards that use it. Otherwise you’d have to update each board manually. Why is this important? Let’s say the UI team deprecates the label “ui” in favor of “ia” for information architecture and “vizd” for visual design to better classify incoming work. Abstracting this logic to a filter allows you to make the update in one place rather than on every Agile board that has a Quick Filter. Pretty cool, aye?
If you found this helpful, please visit Atlassian University – interactive tutorials and videos with tons of tips just like this one.