A question we get asked a lot and which is asked a lot in tech organisations everywhere is: “Which Jira issue type should I use?”

While the answer can differ a lot between different teams and organisations, there should always be a clear answer for your team as to what type to use.

So consider the below as less the exact way to use these types but more as inspiration for how you might document and drive adoption of your own recommendations for teams in your business.

The stock-standard Jira Issue Types

I’ve found the most succinct and easy-to-follow approach to describing how different Issue types should be used is a table like the one one below. The actual recommendations here are what I’ve found to work the best in the teams I’ve worked with.

*The Bug issues themselves might not necessarily be resolved in a week, but the investigation should be completed and next steps identified in this time.

A table like the above is intended as a “quick reference” that helps teams to choose the most suitable issue type, most of the time. The recommendations in it are just ones that I’ve found to work best for most teams.

Bugs?

I could (and probably will) write a separate article just on the fine art of writing excellent Bug Tickets. But my recommendation here is to be clear on what a bug ticket is for and what it is not.

Are bug tickets used for production defects? Are they used for QA tickets on work pending deployment? Both? Do they have the same content? What about incidents? Should bugs handled at a higher priority than regular issue during backlog refinement?

The clearer you can be about how you want people to use the Bug issue type, the more value you will unlock.

Let me know if you want me to write that bug ticket article!

Should I add more Issue Types?

Adding further issue types is a great way to go if you are require some issues to handled in a very distinct way. The distinctions here might include things like:

• The fields that you wish to capture as part of an issue
• The priority by which these issues are handled
• The workflow you wish to apply to these issues

Bespoke issue types really work well where there are multiple, meaningful ways in which these issues differ from the standard types. They are less effective when the differences are more subte. It can make the decision of whether to use them or the standard types more difficult.

Other disadvantages of using custom issue types can include:

• The overhead on implementing, maintaining and driving the adoption of the new type
• The fact that some Apps and standard reports are heavily tied to the standard types

Try to avoid creating additional types unless you really can’t get by without them. Even then, try conducting a pilot of your new type with a limited scope of users / work or time to properly assess whether it contributes meaningfully to a better outcome.

Should I add more hierarchy

In the past, I would have said, “Yes, absolutely!”. The most common use case for historically tends to be bundling a collection of epics into a larger container of work for say a Feature or Initiative.

Whilst you can do this, there are newer Jira extension products such as Jira Product Discovery that are a much better fit for solving some of the problems associated with managing work at a more strategic level.

You can also use Plans in Jira Premium to group your work by Component or Tag which you can use to describe the body of work. This is particularly useful when there isn’t a need to have the content or behaviors associated with an issue. (Summary, Description, Dates, etc)

Jira has also made it easier to add hierarchy on a more adhoc basis by being able to nominate a Parent for any type of issue. (requires Jira Premium) This more free-form approach means that can apply more hierarchy on a case by case basis without needing to implement more issue types and custom fields to manage the relationships.

My general advice here is to keep it simple and use as much of the default hierarchy as possible and explore some of the new functionality available to see if it is a good fit for what you are trying to achieve.

In summary

• Having your own guidelines for what issue type to use and for what creates both speed and consistency
• A tabular reference / guide is a light-weight way to represent this guidance
• Use custom issue types and heirarchy sparingly and only if needed
• Pilot new types prior to pushing for full adoption to validate that the improvements are real

Photo by Robert Katzki