Why I Finally Ditched JIRA
When I originally transitioned away from Github Issues (years ago at this point), my company already had JIRA installed and I figured that would be good enough. And it was, for a while—but a number of things drove me crazy, and eventually made me utterly dread using it. Since I’m trying to organize the architecture of a product line, I’m using the project management tools more frequently than individual developers, and the little aggravations really add up. But there was a single thing that finally broke me and forced me to switch—read below.
JIRA is basically the Salesforce of project management: A bloated, ineffective UI painted thinly over a bloated, ancient database comprising countless miscellaneous fields.
- Speed: JIRA’s cloud-hosted application is EXTREMELY SLOW. For some individual developers, this wasn’t much of an issue, because they might only use it once a day to update a few tickets and forget about it. For me or anyone else trying to organize and understand the project as a whole, it started to feel just downright useless. Every single operation takes seconds. Loading our main Kanban board takes anywhere from 4 to 15 seconds (!!). Clicking on a single ticket to view its details takes up to 6 seconds (!!!). The best I can hope for is a couple hundred milliseconds for any given operation.
- Outdated/Senseless UI: But it’s not just the network latency that contributes to an overall slowness: it’s the UX design itself (or total lack thereof). From the Kanban view, clicking on a ticket opens a sidebar that squishes all the ticket cards so much they’re unreadably useless (unless I have it fullscreened). In order to change any information that the sidebar doesn’t happen to show, I have to click a menu button, then edit, then potentially page through the issue options in order to make the change. But the worst aspect of this is:
- Slow, Ineffective Search: Searching for tickets is actually one of the most critical elements in a project management system: during a sprint meeting, say, you often need to see if a ticket was already created for the issue at hand, or find one you know is being referred to. In JIRA, you type your search, then wait several seconds while a flat, paginated list comes back, containing ALL possible tickets, including completed ones, without any obvious distinction/sorting, across all JIRA projects! And if you made a typo, or you weren’t exactly sure what the right search term was, you get to do it all over again!
- Confusing Organization: It’s very difficult to do any kind of meaningful high-level organization in JIRA. I’m talking about product-level planning, sorting ideas into epics and stories and seeing a clean, filtered view of those. For instance, Epics are represented as cards in the Kanban view like all other tickets, and so you find yourself asking: wait, do I put this ticket in “In Progress” AND the Epic ticket in “In Progress?” What do I do with this extra epic card hanging around? They are not automatically or graphically linked in any way in the Kanban interface, so you end up with this extra epic card that noone knows what to do with.
- Confusing—or Outright Broken: JIRA appears to have some kind of release management workflow, but I’ve never been able to understand it, and I’ve never been able to use it to do anything but make things worse. There’s a “Release…” link above the “Done” column, so I once thought, “Oh, ok, when we release a version we just click that and it flushes all the tickets and we have a kind of clean start for the next version.” But no! It turns out that, if you have multiple Fix Versions (which you shouldn’t be able to do in the first place), and any of them are not part of the release you’re trying to make now, it will fail—but it will add that failed release to the fix versions, making it actually impossible to ever release those tickets (without, I suppose, using the API to manually remove everything?)!
- Configuration Paralysis: JIRA is basically the Salesforce of project management: A bloated, ineffective UI painted thinly over a bloated, ancient database comprising countless miscellaneous fields. There are so many possible settings and configuration options, starting in on customizing anything can easily lead to confusing and difficult-to-debug problems. In fact, the straw that broke this camel’s back for me was that another team in the company changed our “Issue Screen Schema” in a way that literally made it impossible for me to create Epics, because a required field wasn’t included in the schema, and despite 3 different attempts, I could not figure out how to fix it, nor could anyone in IT. This is an utterly absurd situation to find yourself in with software that you pay good money for.
- Nonexistent Support/Improvement: Say you set an issue resolution to “Duplicate” or something and then realize the ticket has to be reopened. You’d want to change the resolution to “Unresolved,” right? Guess what: people have been requesting this for LITERALLY FIVE YEARS to absolutely no avail. There’s literally no way to do it without stupid workarounds.
- …and all the other tiny little things that add up, like scrolling down, clicking in a box, hitting ‘delete’ and typing a number in order to specify story points. And that’s only if you’re already looking at the issue modal. If you’re not, you need two more clicks to get to that.
I probably don’t need to tell you that even tiny UX frictions add up and results in wasted time, user frustration and secondary effects, like spending less time writing good tickets because it took so long to use the software. And if you say something like, “Well, you just need to configure JIRA to better suit your needs”—No. I don’t want a one-size-fits-all monstrosity, I want software that’s tailored to agile development. And that’s how I ended up moving to Clubhouse.io—read about how I did it.
As a product designer, I know I have different standards and criteria than some others, but I’d love to hear your thoughts—please comment below.