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.

[Andrés Vallenas]

Hi @Walter Buggenhout:

Actually, we unified our projects into one to keep the same Epics for everyone. Instead, we are using components to filter issues in the way they were by using different projects. Do yo think that's enough? I thought that was the best way, because we are using epics to track how each part of the whole project is being developed and those epics are the same for every project we had. (for Android app: chats, contacts, calls; for iOS app: chats, contacts, calls... for Component: epic1, epic2, epic3... and so on)

[Walter Buggenhout]

Hi @Andrés Vallenas,

Did you know you can use Epic cross project ;-)?

My 2 cents - I would rather expect Android App, iOS App and similar things as components while Epics would be, well ... Epics.

BUT (and note the caps there), I have little to no insight in your data. And if things are working for you the way you set them up right now, that's what matters most. 

[Andrés Vallenas]

No way, @Walter Buggenhout,
I know I can use same epics of one project in different projects but they don't seem to appear in the backlog.
They are working almost fine but we encountered another problem.

While in the filter of, for example, iOS (component = iOS) we can create issues and it will automatically fill the component field to iOS. But doesn't seem to work with Android for some reason. Can you explain why?