Issue naming

Andrés Vallenas

I recently post a question about epics, components and multiple sprints. Because I entered to work in a company that is already using Jira. But they've been using it wrong.

I solve the "one product, one project" problem, because they had several projects for the same product. Now we are not sure if our issues naming is correct. My boss ask me to find some kind of formula about issue naming, so that every issue would have the same "type" of name.
We need it because our issues have such long names that they are no readable in the backlog.

I would like some advice

Walter Buggenhout

Hi @Andrés Vallenas,

I am afraid there is no silver bullet answer here. The main issue you point out here is that names are currently not readable in the backlog. As a rule of thumb, you could insist that the issue summary should fix that and have a clear and descriptive title, no longer than the number of characters you can read in the backlog view.

The title should simply state what the issue is about, and do it concisely.

I would strongly advise against creating some naming convention for the issue titles, as that would be user dependent, error prone and not useful at all for categorisation or reporting purposes. Rather use other Jira capabilities for bringing structure: issue types, Epics, components, custom fields, labels, ...

Just a few examples:

Since you previously had multiple Jira projects for the same Product, I guess you have replaced the previous projects with Epics. They are a perfect replacement and allow to filter the backlog view by them. They would eliminate the need to include any kind of previous project reference from the issue title.

Use distinct issue types to clearly distinguish between different types of work in the backlog and avoid things like "BUG: ..." from your issue titles.

Use the built-in priorities field to mark the relative importance of issues, rather than doing something like "REALLY SERIOUS Incident: ..."

They might be obvious and you might have considered those already. But to summarise: the summary should just mention what the issue is about. Everything else, required to categorise the issue is better stored through different categorisation options Jira has to offer.