JIRA 101: Utilising Quick Filters in Scrum Projects Efficiently

So, as most tech companies know, using Scrum Boards in JIRA come with many benefits. Now, no matter which tech company you work for, there will always be similarities in the types of scrum workflows that are set up. But what happens when there are far too many issues in your sprint that relate to various different skill-sets, tools, features or other? How do you filter and keep track of what stage some of these issues are at without having to fish through a bunch of Jira tickets to find the ones you’re looking for; and you know the limitations of ticket summaries when there are many columns in your active sprint view — yep, that’s right, they’re cut off from full view. So you have to either click them to open the preview panel, or hover over each one to see the full title.

So here are a few cool ways I wanted to share on utilising Quick Filters in viewing your tickets in a more clean and transparent way.

1. Using Labels

Adding a label to a ticket is really easy. Just Edit the ticket and in the Labels field, add a new or existing label that is relevant to that ticket type.

Examples: “Design”, “Development”, “Investigation”, “SQLScripts”, “Documentation” etc

Then when you go into the board configuration, under Quick Filters, simply add a label with the JQL format:

labels = “Investigation”

And you can do this for all of them. The downside? You will have to spend a lot of time labelling up all your tickets, and then comes a training piece to your team to remember to add the correct label in this format for all future tickets.

2. By Team Members

I’m seeing this happen more and more often in various projects. Those teams who have dedicated developers and testers, would sometimes like to see tickets assigned to relevant team members. This is because the Scrum framework dictates that the scrum team should self-select the tickets they will work on based on their skill-set.

So to do this, simply go back into board configuration, and under Quick Filters, simple add this filter format:

assignee = “John.Smith”

The Downside? All tickets should be assigned to the relevant person. Even the ones that are still yet to do. But the other downside is that how do you assign a ticket to the QA Test Member, without the ticket getting through development first? Therefore it would be assigned to the Developer first. But this would work to see what tickets are currently being tested.

3. By Release (Fix Version)

This is one of my favourites. In a sprint, we usually have items that are prioritised by the Product Owner to be released in separate increments. And there are those releases that sometimes do not need a deployment, but instead require an SQL script to be run direct into the database.

So working alongside the PO, we create the Release Versions from the Backlog view of the Scrum Board, and name them appropriately in terms of the type of release. Examples:

• Feature Release v1.0
• Database Scripts Pre-Launch v1.0
• Investigation Spikes v1.0

Then in the backlog, you drag all the tickets from the current sprint into each of these versions that were created. This has a very good advantage in the sense that it allows Product Managers to get a good idea on how far the tickets are from completion, relating to a particular release. Usually, PO’s outline release dates to stakeholders for specific features of the product, and using this format is probably the most beneficial for them.

Then go into the board configuration and add the Quick Filters using the following format for example:

fixVersion = “Feature Release v1.0”

Downside? For projects that last months and go over several sprint cycles before launch, it may not need to be released anywhere for a long time, other than to a staging or beta environment.

4. Hiding Completed Tickets

Another trick that I found really helps PO’s from being overwhelmed by the active sprint view, is adding a quick filter to hide the tickets that are already completed (Marked as Resolved or Closed). This brings only the tickets left to complete in view. This is also a good view for Scrum Masters to keep track of progress of the sprint (as the aim is to have no tickets visible using this quick filter by the end of the sprint)!

Add the following label in the Quick Filters section of the board configuration:

status != “Resolved”

5. Hiding Sub-Tasks

One thing I add to ALL my projects, is the filter to hide sub-tasks, as developers tend to break down a lot of user stories into sub-tasks, but the Active Sprint view gets long-winded and PO’s then find it more tricky to find the tickets that they raised, amongst all the Cards that are visible as sub-tasks, which the development team most likely would have created.

This would allow PO’s to see all the Parent tickets that he/she would have raised. In the board configuration, add this Quick Filter:

issuetype in standardIssueTypes()

6. Showing Parent Tickets and Sub-Tasks Assigned to Epics

If a lot of you’re user stories/bug tickets are assigned to Epic’s, or perhaps they all are, then this is a really great solution for you.

It’s easy to add a filter for parent tickets that have an Epic assigned to it. But Sub-tasks do not have a direct association to the Epic, as they are controlled via the parent. So how do you do this?

Lets say in this example, we have a Epic with Ticket Number: “DEV-23”. Go into the Board Configuration and under Quick Filter, add this JQL to show BOTH the Parent’s, and Sub-Tasks where the Parent has this Epic Link:

“Epic Link” = DEV-23 OR parent in tempoEpicIssues(“DEV-23”)

Thoughts?

If you liked any of these idea’s, please let me know you’re comments.

Or if you have any other ideas on Quick Filters you’d like to share, please feel free to do so!

All the best,

Umer Saeed | Scrum Master