Issue ID usability

[Inna S]

Hi, 

a newbie here.

I see several troubles with Jira Issue ID and would like to understand how this is ok for everyone.

1.  There is no way to tell the issue type by looking at the issue ID. The only indication is the tiny icon that can mean one thing in one project and another thing in a different project. There is no text representation of it. It is against all the basics of the usability and I wonder if this can be changed.

2. Issue ID contains the project identifying prefix. So when we move issues from one project to the next, or rename a project, the issue itself has its ID changed. 
This is a problem when we need to track items and refer to them externally.

I guess there is some internal ID for every issue and wonder if the Issue ID can be replaced by a custom field that would be a combination of the <issue type> + <running number within the issue type>?

Thank you

[Nic Brough -Adaptavist-]

Welcome to the Atlassian Community!

1. Yes,, the issue key is for showing you the unique key of the issue.  The issue type field is for seeing the issue type.  In a lot of places, it's shown as an icon, so you should be selecting distinctive icons for them, but you can also hover the cursor over it to see the name.

I'm guessing you're coming from a legacy system which used the primitive and unhelpful trick of encoding the type into the key, leading to people having to be told what the cryptic thing meant.

Jira's view is more usable than that, you don't have to educate people on how it works.

2) Yes, the key reflects the project.  Generally, moving an issue to another project is something you should be doing when housekeeping or when a genuine mistake happens where someone creates the issue in the wrong project.  If you're moving issues between projects as part of a process, you've got a broken process and you should be looking to correct that.  The issue lifecycle should be done by the workflow, not by changing projects.

Moving projects is recorded in the history, and the old key remains usable (note that it wouldn't if you encoded the issue type into it, this is one of the reasons has better usability than those legacy systems).  If you move ABC-123 to DEF-456, you can still search for, or visit https://yourjira.atlassian.net/browse/ABC-123 and you will land on DEF-456.

So the short answer is "no".  You can't replace the issue key with something less usable.

[Inna S]

Hi Nic, 

appreciate your quick and elaborate response. 

Unfortunately this confirmed my initial understanding about both the tool and the community. 

Different organizations work in different ways and slapping a newcomer right away by telling them their work process is all wrong just because a tool does not support it is a bit strange. 

Not everyone here has a 20:20 eyesight, some people are color blind and so using the tiny icon to convey a critical information is a big no in UI design. In fact it does not stand the UI standards.

Reassignment of the work item happens on a regular basis, this is normal. 

Anyway, we will continue to search for the ways to adapt the tool to the business needs, even if it takes more effort and makes the work less intuitive.

Thank you.

[Nic Brough -Adaptavist-]

Of course organisations work in different ways, Jira is built with huge flexibility and power and supports many ways of working.  

I'm not saying your process is broken because Jira doesn't support it, I'm saying the process is broken because it involves restructuring the entire issue and all the data on it, and moving it between different processes.  A working business process has a single lifecycle for an issue. 

It sounds to me like your processes have been broken by being forced to use a tool that doesn't work properly.  Your processes shouldn't need you to re-engineer a data structure just becomes it gets reassigned.

I agree with you on the visibility thing, but that's why you can pick different icons for the issue types.  When people's eyesight is bad enough to not be able to distinguish them, then they're able to use the tool tip (or even a screen reader), which would be a lot harder to do if the issue type were encoded into the key

[Inna S]

@Nic Brough -Adaptavist- you do not really call a work process followed by a company unfamiliar to you 'broken' just because it is not what you are used to see, don't you?

[Nic Brough -Adaptavist-]

No, not at all.

I call them broken when someone has given me enough information about them to see that they are.

From what you have said, your process entails changing the structure of the issue you're trying to track (including its human-friendly unique id) when it changes teams.  That does not sound right to me.

The analogy I was given years ago was a simple car journey - your customer wants to be driven from Londong to Liverpool.  Imagine the car is the issue, and the driver the assignee.  If, for some reason, you need to swap drivers at a stop near Birmingham, does that mean you're also going to should change the car into a motorbike, and obviously, the registration plate for it?

No, keep it in one project, don't change the car or the licence, just adapt your process to not trying to do that (as I said, it sounds like you previously let the legacy tool determine the process to fit around the way it wasn't very good at issue tracking.  You shouldn't do that with modern tools - define the process and configure them around it)

[Inna S]

Where did you see the " process entails changing the structure of the issue"?

In the world where the project represents a small group of people working together on similar issues, these issues sometime need to travel. The issue itself retains all its 'identity': ID, name, type, all the fields and attachments, links to the parent and children, dependencies and all. The only thing that changes are the project, that is a basket with an optional time frames, and the individual owner.

So that everyone involved with the work already done on the issue can continue refer to it by its known ID. Track it. Talk about it. Communicate in an intuitive manner outside of Jira. (Yes, I've read the Jira intro insisting all the communication has to be done in the tool. This is not how the real world works.)

Jira treats inter-team reassignments as a big bang migrations, and you seem to be blinded by the Jira way to the point where you assume any other tool takes the same approach. It doesn't.

It looks to me the flexibility-complexity balance in Jira is less than optimal, but I'm not loosing my hope yet.

[Nic Brough -Adaptavist-]

>Where did you see the " process entails changing the structure of the issue"?

When you said "when we move issues from one project to the next"

That's changing the structure of the issue. 

This is because of what a "project" is in Jira.  You've aligned your "team" with "project" which is not a bad thing, but it doesn't work when you have issues that several teams need to work on.

A project is a structural configuration that controls how the issues it contains work.  Changing the project is a structural wrench - you are changing the identity of the issue, its ID, and potentially many of its fields, and, most importantly, the process or lifecycle of the issue when you move it to another project.

Jira does not treat inter-team reassignments as big-bang migrations.  You do.  Because you are aligning team = project.  If you move to the way Jira is intended to work, you won't cause any of the problems you've inherited from your legacy systems.

What you should do to fit Jira to your business process is stop aligning team = project.

Treat projects as containers for issues, and let your teams select issues from many projects based on other criteria.  Team = Board is the one Jira is built for, and that gives you a huge flexibility.  Something needs attention from a team based on almost any rule you want to think up.  

If you do that, then you're no longer forcing big-bang migrations onto your issues or teams when you change the team.  In fact, you probably don't even bother changing the team, you only really change the "team currently responsible".

As an example, I'm currently finishing off moving someone from Remedy to Jira.  They've got seven core teams, and started off with project = team, which actually worked ok when the teams had no cross-team work (they did have dependencies), but they've started to need cross-team work, so they had to break up those siloes.

They've built workflows that work for all the teams, and put all their shared work into one project.  Their teams now have boards (or queues) that work from "Project = <team project> or (Project = <shared project> and our team is flagged on the issue"

[Inna S]

Now we are talking!

So team=board is the Jira way, right? And the whole org can have all its work in a single project?

Where do I keep the releases then? I have several products, all have their own set of releases, past and present.  I see that Jira versions are attached to projects and can be filtered upon on boards. 

Then what about an access? It comes from the schemes and schemes are attached to projects, not to boards, right?

Can you point me to the good tutorial on the subject of structuring please? What I saw so far is a bit shallow and does not answer even basic questions I have at this stage.

Some demo cases featuring middle size hw-sw corporation?

Thank you

[Nic Brough -Adaptavist-]

No, look at the last two paragraph in my previous comment.

From your release comments, you probably should be thinking about one project per product.

[Inna S]

Back to square one.

I actually started thinking of a project per product and board per team within the project.

But then we casually move things from one to the other and this is where it all started. 

[Nic Brough -Adaptavist-]

It does sound like that would work best for you!

But you'll want to tell people that moving issues between projects is not part of your process.  It does not sound like it should be, if you can do "project = product" (which makes a lot of sense because you can take full advantage of project versions and components) and "board = team" with boards that select issues from all the projects a team needs to work on!

[Inna S]

This could solve the dev and cross-portfolio teams needs. 

But how to manage the 'customer' bugs then? Ultimately the fixes are done and released as part of the product release. But they are often initially 'reported' on one product and then the fix comes from a different one. Today the issue is moved between the products retaining all the rest of the info.

If I place all the 'customer' items into a single project to facilitate the moves between products, I'll lose the release info, allocation, PI and scheduling. 

What is the accepted practice?

[Nic Brough -Adaptavist-]

There's a fundamental question of why are you creating customer bugs in the wrong place?

But when you're in a place where the people creating issues don't know where they should be added, there's a standard approach - use a helpdesk style project.  Customers can raise everything in one place, and the agents who "triage" the incoming issues can ask them for enough information for them to route it to the right project, creating a new development issue in the right place (if you're using Jira Service Management, there's even a link for "create development item in a dev project", and it maintains a link between the customer issue and the development on)

[Inna S]

Sometimes issues manifest themselves in one place but have the root cause in another. Support has no ways to know, even the dev team is often not sure. 

Currently I plan to have our support (high level, not customer facing) work in the Jira Software dedicated project, don't think Service Management is on the table, for various reasons. 

[Nic Brough -Adaptavist-]

Yep, most use the same principle - a project to handle things you don't know where they land and then a new issue in the right place when you've worked out which area(s) need to work on it.

[Inna S]

Well, this might just work. 

Is capacity calculated per team(=board) to account for work in several projects?

[Nic Brough -Adaptavist-]

You can calculate by project, board or, with a bit of fiddling, almost anything else you want to.  Boards are however easiest - Scrum boards give you a velocity (so you can easily see how much the team can take into the next sprint) and Kanban give you a throughput, so you can see how much the team is getting done regularly.

[Inna S]

Thank you, will try this.

[Craig Nodwell]

Hi @Inna S welcome to the community.
Quick question for you
Where are you viewing this "Issue Key" & "Issue Type Icon" combo?  There may be ways to manipulate what you are seeing depending on where you are looking at it.  Also yes, Jira does have an under the hood issue id.  Issue Type icons should not change from project to project unless one project has an issue type that does not exist in another or the project is a Team Managed Project.

[Inna S]

Hi @Craig Nodwell , thank you for stepping in.

I see these everywhere. the Plan and My Work list are the worse because it does reveal the type even upon mouse over event, but they are also displayed in other locations.

We move work items from team to team all the time, especially when we need to consult one another, check things etc. Tracking items that keep changing their ID is a nightmare. 

Not to mention the customer communication where the bug id would change depending on the team that handles it.

I plan to have company managed projects.

[Craig Nodwell]

Hi @Inna S I wish I had better news for you.  There is a feature request that you can vote on.  On that request there is a suggested work around that you can probably implement again not the best but at least it is something. 
Please note I do not work for Atlassian, I just like to help people.
Seems this has been an issue for a while now, and other people have felt your pain.
As per this post

Voting on the feature request will bring more awareness to the importance of this feature.

[Inna S]

Thank you @Craig Nodwell . Your input is helpful even if not encouraging :(. I just read the comments there and I'm now looking for an emoji of the head-banging-against-the-wall.

Voted for the request though. 

Thank you.