Skip to content

Why I Finally Ditched JIRA

2016 September 8
by Tedb0t

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.

See this post for how I moved to (and how you can too).

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—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.

Related Posts:

3 Responses
  1. Chris Rosenau permalink
    September 9, 2016

    Basically that is why we went to Teamwork Desk.

  2. September 9, 2016

    Hey Ted,
    Sean from JIRA here. We are never happy to hear you are not happy. There are lots of new tools popping up all the time and we understand the excitement that comes with finding a new one. I’ve read both of your extensive blog posts today as well as the slide deck you made and I’d like to offer some thoughts on the things we are doing or have done to address your concerns inside of JIRA.

    Speed: We’ve got some major projects that will be coming online soon that will fundamentally accelerate the platform. This isn’t a small tweak, this is a core architectural improvement that will make a big difference across the board.

    UI: Have you tried collapsible columns? This will let you minimize columns you don’t care about so the columns you do care about are bigger allowing you to see more of the ticket. Managing your backlog as the first column in a Kanban board is ok when there are only a few issues. But, as your backlog grows it’s hard to see many issues on the screen at one time. We’re going to let you split the areas of concern into two different screens with each one focused on the tasks at hand. The backlog is for backlog management and replenishment; the Kanban board for the engineering team to select and move the tasks through the workflow. This cuts down on noise and makes better use of your screen real estate. We are looking at a redesign for the issue view but more user research needs to be done.

    Search: That’s good feedback…and something that we hear from customers who have larger and larger issue counts. I’d like to break your comment into two pieces, the speed piece and the effective piece.

    Regarding effective searches. We want to make sure everything in JIRA is searchable and JQL is super flexible. But, we also make sure it is easy to filter down to the specific information you need. In this instance, I’d advise doing the search the way that you have, and then using the status filter to separate out open issues.

    In basic search, you can quickly toggle things on and off, for instance, issues that are resolved. This should give you the sorting functionality that you are looking for.

    Regarding speed. We are working hard on performance. You will see big improvements here as we keep focusing on performance over the next 6 months.

    Epics are currently displayed as cards in Kanban and this works well for certain use-cases. However, you are correct that it makes it harder to identify what issues are associated with the epic and if used as a grouping mechanism, displaying the card on the board isn’t as useful. That’s why we will provide an option in the future to display Epics on the board, or use it as a way to group stories the way we already do it for Scrum.

    To answer your broader question, here are a few more ways that help you organise your work in JIRA:

    Kanplan: A great way to keep this work organized in JIRA Software is through the plan mode (aka backlog) which can be found when using scrum or the Kanplan feature in JSW Cloud. Trying to run a backlog and team task board together is distracting. Managing your backlog as the first column in a Kanban works great when there are only a few issues. But as your backlog grows it’s hard to see many issues on the screen at one time, the cards are large and the ones you care about are confined to ¼ of the page width or less, there’s so much scrolling. Splitting backlogs and tasks to two different screens with Kanplan helps- Backlog is for backlog management and replenishment and the Kanban board is for the team to select and move the tasks through the workflow. You can tab between Versions and Epics to see the progress of an Epic (e.g. number of issues, completed, unestimated, estimated, and even linked pages). Also, from this view you can mark the Epic as done and edit details.

    Portfolio for JIRA: If you are interested in cross-team and cross-project visibility then a tool like Portfolio for JIRA would be a better solution. In about 2 minutes Portfolio automatically pulls together a view across all projects to show you the what-ifs for everything you teams are working on as you do resource planning in real time. With Portfolio for JIRA you can combine the work from multiple agile teams and roll them up into larger Initiatives. Think of Initiatives as higher-level business priorities or big projects potentially spanning multiple teams. When you look at Portfolio for JIRA you can see a visible roadmap, which can be viewed by Initiatives, Epics, and issues. And, if you want more levels, Portfolio for JIRA provides an unlimited hierarchy, so you can create levels above Initiatives and Epics to help bring organization to how your team works.

    Product-Level Planning- I’m not sure I fully understand what you are looking to do here. Happy to help if you want to explain more.

    Config: JIRA Software was designed to be flexible and customizable and admins have set JIRA up to fit how their organization works. The issue here could be an administrative matter – schemes should be for global or project admins to change and it sounds like in this instance that too many people have access to these permissions. As teams grow it is important for teams to spend a little time dedicate time to the to thinking about how they want their own team to work. We could take the flexibility out but dev teams really appreciate being able to customize the way they work. In order to be a true agile tool, the setup needs to be flexible to meet the needs of many different teams. As a result, it is important to use permissions properly – this might mean that there is a council of stakeholders who go over customization asks, or there is an admin who is constantly working to improve and meet team needs.

    Support: Based on the info we have from you the solution seems like it could be simple here: create a workflow transition from duplicate to resolved. In the current state, it looks like the workflow doesn’t have that. If that doesn’t do it, let’s work together with our support team to figure this out.
    UX: Hell yes. We agree, killing UX friction is always important. We’ve shipped a few things recently that should help if you haven’t seen them.

    Editable Fields: We’ve added more editable fields to tickets. Editing or updating details for an issue was not possible for most fields in the Agile detail view. Most users click through to the view issue page to edit an issue and then return to their board. This is slow, inefficient (several clicks and 2 full page loads) and context is lost during this roundtrip. (MEH!) Now you can edit right in the issued to that the user can stay in context and make quick, efficient edits. This saves time and eliminates loss of context. (Plus it means fewer tabs open in your browser.)

    Collapsible Columns Make your screen real estate easier to manage.

    Redesigning Agile Cards: We’ve redesigned the Agile cards so that in situations when column widths are small the cards can better communicate their content. This might happen when: Screen width is small, many columns exist or the sidebar and/or detail view is open.

    To help fix that we worked on the following with the redesign:
    -Improving the visual styling with a focus on ‘glanceable’ information
    -Creating a density option
    -Updated selection, hover & flag states
    -‘Days in column’ indicator
    -Improve stacking at small widths
    -Introduce sub-tasks attached to their parent in Kanban
    -Explore plan mode sub-tasks

    -Sprint Permissions-We’ve improved sprint permissions. These can now be assigned to individuals, groups and roles and is decoupled and independent from Administer Projects permission. This enables simpler administration for group or role management e.g. ScrumMasters (often contractors) to work with teams successfully, and with minimized risk to the organization for unauthorized changes in the project.

    Repo Integraton: On top of JIRA UX improvements, we’ve done a lot to help take UX friction out of the interaction between the repo and issue tracker.

    -Create Bitbucket branches from within JIRA Software- JIRA Software will automatically populate information for your new branch in Bitbucket and even suggest a branch name based off of the issue key.

    -Transition issues in JIRA without leaving Bitbucket- Tickets in JIRA automatically transition when the dev merges, commits etc. This means the devs can stay in code but the project manager can see the activity and if there is a need to go back to and look at the issue and the code there are tied together automatically.

    -Give your entire team end-to-end traceability- Track the health and status of your next release from day one of development in JIRA Software’s Release Hub. Release Hub talks to Bitbucket to ensure that done code is really done and there are no inconsistencies or launch risks prior to launch day.

    There is always more we want to do and we take feedback seriously. Hopefully, this helps fill on some gaps and address some of your concerns. —

    Sean (I work on JIRA)

Trackbacks and Pingbacks

  1. How (and Why) I Switched from JIRA to Clubhouse | Limina.Log

Comments are closed.