Things Developers Believe About Jira

[#1]

First, let's name a few things

If you have an issue TEST-1234, then that whole thing is called the issue key

The project key is TEST and the issue number is 1234

A project with the project key TEST also has a project name, which is something longer such as "Testing project for the Test Team"

Right, now let's correct some things that developers might assume when they try to integrate with Jira.

Project names and keys are constant

Not so. Project names are really easy for a Jira administrator to change, they're just a bit of text.

And Jira administrators can also change those short project keys. 

So TEST-1234 might one day become QA-1234

The issue number part won't change, and the Jira UI will nicely redirect you to the new issue key.

But don't assume that a project key will never change.

Issue keys are constant

This is even less true than the previous thing that wasn't true.

Issue keys change all the time when users move issues from one project to another.

If I move TEST-1234 into the ENG project, then it will change both its project key and issue number. 

It could become something like ENG-2345, with a totally unrelated issue number

The Jira UI will still redirect you to the new issue key, so this isn't usually a problem.

Every Jira issue does have an underlying issue id that never changes, and it is just an integer.

You don't really need to use the issue id though, because the redirection to the new issue key just works.

Workflows and their Statuses are mostly the same in all of Jira

Sadly, this is rarely true. Jira workflows are made up of statuses, with status names such as "To Do", "In Progress" and "Done".

A specific Jira issue's workflow depends on the Jira project that it is currently in, and the issue type. Issue types have names like "Bug" and "Feature".

Just because a Bug in one Jira project has a status named "Done", this doesn't mean that a Bug in a different Jira project will ever have that status too.

To add to the fun, Jira administrators can create new statuses. One day I saw a status named "Done Done", which made me laugh.

Sometimes what one person thinks is an obvious meaning for a status name is not always shared by someone else.

For example, "In Review". Is that for before the work is done, or for after the work has been done? That depends on where someone has put it in the workflow.

Options are constants

Options are the values in Jira drop-down fields. A drop-down field has a set of options that people can choose from.

The same custom field can have a different set of options depending on which Jira project an issue is in.

The option names can change, but their option ids will stay the same

It’s easy to add a field to all projects

Would that that were true. To add a field to a Jira project, you have to find the particular Jira screen that an issue is using.

Which screen that is depends on both the project and on the issue type.

So, the follow-up question is always "which issue types should the field be added to?"

The next hassle is when a screen is used by many issue types in a project.

For example, if a screen is shared by Bug issues and Task issues, and you want to add a field just for Bug issues, then the administrator has to create a copy of the screen, add the field to the copy, and configure the project to use the new screen for Bugs. Phew!

You should get your own custom field

Well, perhaps. I blame the English language for some of the confusion in this case. 

People ask for a "new custom field", but often really mean "an existing field that will be new to our project".

The performance of Jira is directly related to the number of custom fields that have been added. So we can't just create them willy-nilly.

That means that if you are asking for a "brand new to Jira custom field", then the questions from your Jira administrators will get more detailed. For example:

'Will this new field be useful in other projects?"

"Do you need to write reports based on this field, or can you store the data in a different field?"

"What makes you so special?"

Custom field names are unique

You'd think so, but that is not in fact the case

And in various places in the Jira UI, you can end up seeing multiple choices with the same name, which is confusing

When you are looking up a Jira custom field in code, use the unique custom field id instead of the name.

There are no limits to how many times you can edit an issue

Oh, yes there are! Jira keeps track of the history of an issue in the History tab. Almost every change creates an entry there.

After some thousands of edits, the issue will take a long time to load. Eventually it won't load at all.

This is usually only a problem when scripts are editing the issue.

After all, how many times are real people going to edit an issue by hand? Wait, I know some people who might do that. But only a few.

There are no limits to Jira

Now we're getting silly. Of course there are limits. Everything has limits.

The question is whether Jira checks for them or not.

Attachment size? That's checked. But number of attachments? Not checked. So that's an obvious safety gap.

Size of text fields? Checked now, but didn't used to be

Number of comments? Not checked. And adding lots of comments will cause problems somewhere down the line. We're just not totally sure where.

The list goes on, but the most common one I see is not knowing that the Summary field is limited to 255 characters.

It's spelled "JIRA"

Actually, it is spelled "Jira". 

Atlassian renamed the product from JIRA to Jira a few years ago.

That seems like an odd change to me, but I guess that's why I'm not in marketing.

More?

What other assumptions and erroneous beliefs about Jira have I missed out? Send them to me and if I get enough I'll write another article.

[Vero Rivas]

Hi @Matt Doar 

  1.- Believe that it is enough to change states for Jira to do everything else
  2.- Consider that Jira is complicated when nobody bothers to learn how to use it

  3.- Do not investigate all the potential of the product, nor know what is the basics and that it needs reinforcement
  4.- Thinking that it is just a ticket dispenser

  And much more ...

Cheers

[Huw Evans]

Not going to comment on how people pronounce Jira? :)

[Karen Rogalski]

There is a limit to number of issues linked to an Epic. We hit it(was hundreds) and the Activity Streamer Gadget failed for all users, not just for that particular Jira Project. Once the Epic was deleted, all Activity Streamers resumed.

[Matt Doar]

I didn't know about the effective limit of number of issues in an Epic, but I'm not surprised.

[Matt Doar]

One of the things I've learnt from Atlassian and Jira is to not use certain letters in a product name. "J" is a relatively new letter, only a few centuries old, so different languages have widely varying pronunciations for it. "W" is another risky one. 

I wonder now how the metal band Gojira say their name
https://en.wikipedia.org/wiki/Gojira_(band)

[Amy Biasella]

I love Gojira! \m/ As far as I've noticed, they say it exactly like Go Jira.

Jira admins need to be supported by leadership as more than a "Jira can do everything" platform and make room for maintenance/saying no to requests...I know, a development pipe dream!

Using the id for projects/custom fields - if developers aren't Jira admins themselves, that ID is very hard to find without an admin helping them set up their integration.

I smiled at the idea of asking end users "What makes you so special?"...but I've found that question really needs to be sussed out by requirement gathering on the admin side. One group needs a radio button (without "None" of course) and one needs free text and neither will budge, and if you limit what data they can capture, the whole system is useless for them and goes unused.

[Danny DeGregorio _LinkedIn_]

If I move TEST-1234 into the ENG project, then it will change both its project key and issue number. 

It could become something like ENG-2345, with a totally unrelated issue number

I think it's also worth mentioning that if you move that issue "ENG-2345" back to the test project, the issue key would change again and not change back to the old issue key. It would be something like TEST-3456, and as mentioned, the UI would still direct TEST-1234 to TEST-3456. 

[Matt Doar]

"Would that that were true" - this is valid if somewhat archaic English. Apparently not valid American though :)

https://english.stackexchange.com/questions/105919/what-kind-of-construct-is-would-that-that-were-all

[Derek Wailes]

The new Cloud Version is proving to be "buggy" and usability is questionable.
Screens that do not show the correct status of issues are problematic.
The limitation that it does not follow the Scaled Agile Framework for Enterprise (SAFe) Hierarchy is, however, a real showstopper. If we a re paying for a premium product then our expectations are that we get one. Cloud to Cloud migration would be nice too. 

[Mykenna Cepek]

The original post said "Jira administrators can also change those short project keys".

And it also said: "...TEST-1234 might one day become QA-1234 [...] The issue number part won't change".

Theoretically: yes. In reality: beware.

Two years ago I had a project key of ABC which was in-use, but we decided we wanted to use it for a different project. Seems trivial, right?  After all, I can just "change project keys". Nope.

I renamed the ABC project to the XYZ project, which was fine. I was then unable to create a new project using the ABC key. It turns out this is a known limitation documented here.

The listed workaround is to "delete the project it was previously associated with". But we wanted to keep the old project, so I couldn't just delete it. What we had to do was:

1.  Create a new WXYZ project, and move all the issues in XYZ into WXYZ. Note that this DID change the "issue number part" of every single issue.
2. Delete the XYZ project (which was now an empty project).
3. Create the ABC project.
4. Rename the WXYZ project key to XYZ (as that's the key we wanted). Note that this left the WXYZ key unavailable for any future project.

So, our use-case ended up violating both of the quotes at the beginning of this comment.

Note that if we had used export/import in step 1 above, instead of move, we would have lost the key history that allows links to auto-forward to the updated issue keys.

Also, things like filters, searches, and reports which use old project keys may need to be manually updated (have fun tracking all those down). Those do not "auto-forward" as issue links do (another documented known limitation).

[Nic Brough -Adaptavist-]

Hmm.

>Screens that do not show the correct status of issues are problematic.

That really needs to go straight to Atlassian, no screen should show an incorrect status (after a refresh at least)

>The limitation that it does not follow the Scaled Agile Framework for Enterprise (SAFe) Hierarchy is, however, a real showstopper.

Atlassian have "rename Epic safely" quite high on the list - Jira Align is forcing that.   Other than that, there's not much else plain Jira Software doesn't support.  It's not pretending to go above the Feature (Jira Epic) level without apps such as Align or Advanced Roadmaps, which do support lyares of SAFe

>Cloud to Cloud migration would be nice too. 

JMCA supports some of this, and is improving