Taming your JIRA technical backlog

Alon Sabi
Alon Sabi
Jan 16, 2018 · 4 min read

Context

JIRA backlogs tend to get messy over time with hundreds of JIRA tickets that are great ideas but in many cases, there are either not enough resources or a lack of interest to complete these tickets.This blog provides an approach to not only organize that backlog but also to complete it over time.

The definition of “great ideas that are not part of the roadmap” can differ from one person to another. For me, it is anything that we are not already working on, or about to work on.

The road to a clean backlog can take anywhere from a few hours to a few days of effort depending on the number of tickets you have.

We use JIRA at ACL, but no matter what tool you use, this is an approach to taming and organizing your backlog.

Why Bother?

The reasons for organizing the backlog are:

  1. It allows you to prioritize work.
  2. It provides clarity as to the type of issues you have in your system.
  3. It provides better communication between the product team and the development team.
  4. It’s a great place to get new developers focus in to get familiar with the system (cleaning up the backlog, fixing bugs and completing small enhancements).

The Process

We will follow 6 simple steps to accomplish “backlog zen” (Step 7 is completely optional).

Step 1: Identify your definition of “great ideas that are not part of the roadmap”.

Step 2: Write a JQL that represents the definition you came up with in Step 1. Click here for a useful blog to get started with JQL.

Step 3: Create a new JIRA board using the JQL from Step 2. I named mine “Backlog Grooming”. This board should be created as a Kanban board rather than a Scrum board. This means that the board will not be part of a particular sprint, and will always be considered as WIP.

Step 4: Create a new JIRA custom dropdown field named “Area Of Focus”. This field will help you break down your technical backlog into manageable “buckets”. I am using the following options:

  • Product Roadmap
  • Security Concerns
  • Data / System Integrity Concerns
  • Improvements (time savers / reduce error risk)
  • Cleanups (refactoring / removal of unused pieces)
  • Communication Errors (missing or wrong data on page)
  • Missing Command Errors (user cannot perform an action)
  • Error Handling Errors (ambiguous / wrong error messages / wrong errors)
  • Syntactic Error (spelling and other wrong text)
  • UI Glitches (Strange UI artifacts)
  • Control flow errors (system not behaving as workflow suggests)
  • Functionality Errors (anything else / wrong results)
  • Reduce Noise (unhandled exceptions reported or flaky tests)
  • Not Applicable (tickets that belong to others that end up part of your filter)
  • Needs Processing

Make the default value “Needs Processing”

Note: The “product roadmap” option is for tickets that should be evaluated by the product owner for feasibility.

Step 5: Create filters on the board that allow you to see the different “buckets” of tickets. This is the main reason for doing all of this work, so you can easily filter for important tickets.

Note: You can also create project specific filters. That way you can filter for “Project A — Security related concerns”.

Step 6: Systematically go through your JIRA tickets on the board and assign each ticket to an area of focus.

Step 7 (Bonus): Add a pie chart to your JIRA dashboard showing a high level overview of the breakdown of the backlog.

Building a Cadence

There are two important things to care about when it comes to the backlog:

  1. Keeping the backlog groomed.
  2. Reducing the number of tickets over time.

Review & Clean

To keep the backlog groomed, establish a routine whereby you review the “Needs Processing” filter regularly (this would depend on the number of tickets gets added to your system on a daily / weekly basis). I found that reviewing it on a weekly basis works for my needs. Also from time to time run a query for older tickets (tickets that been in the backlog for over 6 months). Ask yourself the importance of the item if its been in the backlog for a long time without being taken care of. Also remember that marking tickets as “won’t do” and close them is ok. If this is a real issue, it will “come back”.

Dedicate time to your Backlog

Depending on your resourcing capabilities It is always a good idea to spend anywhere between 10% and 20% of your development time taking care of the technical issues. My team is currently spending half a day every week working on those tickets (10% of our time). Other teams spend a full day a week (20% of the team time). This structure allows you to focus on an area of focus each week (this week we will take care of security related concerns or data related concerns etc).

Note that the backlog includes both technical issues as well as product roadmap issues. This is simply because non-technical tickets will find their way to your backlog, and you would like your product manager to be able to easily find and prioritize those as well.

My hope is that others will find this process as useful as I have.

Build Galvanize

A window to the product, design, and engineering teams at…