Why I finally ditched Jira

Biggest issue I have with Jira is how it's trying to be the everything tool for all processes and procedures: way too many non-devs and non-qa people looking to get data from it and cramming their stuff into it. Every month it seems like there's another couple of fields that I have to fill out so that some random group can track some metric, or the security team can pretend like we're doing a security audit on all of the code, or whatever. My favorite is the checkbox the QA team has to click to confirm that they've done security checks on new endpoints. They don't have the first clue on how to do that, but they all just check the box because they have to check the box to continue.

Whether or not this is Atlassian's fault is debatable of course. I feel like they were more opinionated back when I started using it ~10 years ago (with the Greenhopper plugin). It was a much, much more pleasant thing to use. Probably because it was only under the control of the teams who were actually doing dev work.

Sounds like a combination of an old version and poorly configured setup. Possibly running on out of date hardware.

I manage an Atlassian setup (Jira, Confluence, Stash, and Bamboo), and we don't seem to have any of the problems described in this article...

Well, except for the configuration part. There's options for almost everything.

The one gripe I have is that, while most things are configurable, there are some that seem like they would be easy to make configurable that get marked off as [wontfix].

Jira support is also pretty amazing. They're also really transparent and dogfood their application and expose their issue tracking to their customers. Bugs filed against Jira are done in Jira.

I totally agree. Complete pile of crap. The search is quite useless (try searching for something as simple as all tickets to which you added a comment in the last week...no chance). Unless you get a plugin, but who writes these plugins? Can you trust them? Who's assessing them? And how much do they cost? And what if you haven't got admin rights? Keeping track of stuff should be the main functionality of the product, it should be slick out of the box. Not to mention all the other stuff, useless kanban boards, bulk operation, and all the rest of it. I find myself clicking for whole minutes to complete simple tasks.

I think Atlassian have too many pots on the fire and they can't keep up with it.

I used to be in the "hate JIRA" camp but have basically done a total 180 on it. I'm convinced that most people that hate it have a poorly configured setup and don't know the difference between the frustrating workflow forced on them by their management, and what the software actually does.

I've never seen a bug tracker with better keyboard commands, more powerful features, more ways of organizing stuff, more powerful querying, but all of that is just under the surface, and waiting for you to discover it. The default out of the box experience is simple, clean, works, and encourages best practices for software development.

As a previous Jira user I have come across all the problems in this article. But the biggest problem with Jira, and all similar applications is that developers just don't want to use it - as a PM you either end up having to force a tool on the team or try and work from inaccurate data (which involves lots of asking for status updates rather than getting them async from the tool)

This is actually why we created ZenHub[1] to take this work flow to the makers rather than the managers.

We find this provides higher quality data and improves productivity by reducing context switching. Im interested to hear everyones thoughts about this integrated approach vs siloed tools like Jira. In my biased opinion the days of having a separate tool for this are numbered (see also the GitLab issue board release)

[1] https://www.zenhub.com/

I definitely see the speed issues with JIRA. Self hosted was a better solution than running on the Atlassian Cloud, oddly enough, but I definitely can relate to 2-3 seconds for actions that take milliseconds using just Github Issues.

I've never loved Jira but instrumented correctly it is 100x more powerful and useful than the lightweight Asanas, Trellos, etc of the world. It's really all about the instrumentation.

Agreed. Instead we use github issues with color-coded and prefixed labels (e.g. "type:bug", "comp:auth",... with all type labels blue, all component labels green, ...) and waffle.io for a sortable kanban view. A few big FOSS projects do this (e.g. https://github.com/angular/angular.js/issues).

Pros: best possible github integration, fast, lightweight.

Cons: none for us. There's nothing in Jira that I miss, at least.

O HAI. You think Jira is bad? Let me introduce you to VersionOne.

Google Cache: http://webcache.googleusercontent.com/search?q=cache:http://...

Every dev team should use JIRA. It is a great, daily reminder of how awful a blotted, over engineered, "try-to-do-it-all" application can be.

One of my vendors uses Jira, so we have to use Jira to submit tickets for bugs on their stack/apps...and because apparently there are some config options within jira, its often tough to tell if the suckiness is Jira itself or how an admin has set it up. Our vendor has had to re-config things twice (and we might have to ask them to do so yet again).

On the flip side, I have another vendor, and they moved to youtrack earlier this year...As a former developer youtrack just gels so well for me; everything clicks awesomely and makes sense. It may not be as pretty as Jira, but extremely powerful for search. My vendor is self-hosting a youtrack instance, and who knows there may be similar config. issues like jira, so YMMV...but have a look-see: https://www.jetbrains.com/youtrack/

I used to be a big Atlassian homer because I enjoyed using their products and they were easy to use. Over time I got into some administration and saw the other side and it wasn't quite as pretty. Did some migrations and those were actually okay but had their share of glitches.

I'm starting to see companies "become Agile" by enforcing Jira usage. It's a sad trainwreck to see. I personally think you get people to buy-in to Agile and then once they do you can introduce tooling that will support their needs, not install Jira with all the bells and whistles on Day 1.

Jira is good compared to Bugzilla and others (not mentioned the complete piles of crap like ClearQuest that couldn't even get basic search right and a "nice" proprietary one that required 2fa for logging in to bugs. Of course it was IE only)

"Kids these days" don't know how long it took for Jira to appear

It is "bad", but it is bad compared to what Google puts out. Not a corporate tool.

At my company we run a locally-hosted version of FogBugz. It's a smaller shop, with about eighty users. And about twenty or so of them are not developers or technical staff, but staff in other departments who need to be able to view tickets and occasionally comment on them.

Like all systems, it's not perfect. But we have no big complaints. What it does, it does well. The search is fast, and as granular as I've ever needed it. One user in this discussion said searching for something as simple as all tickets to which you added a comment in the last week was impossible in Jira. In FogBugz, it's trivial. There are plenty of little conveniences and niceties that Trac never offered (the last time I looked, which was years ago to be fair).

Fog Creek's customer support has been excellent, and they use it themselves to support their users, which we also do. And as a 5013c not-for-profit we get it for half price.

Well, since your own site is throwing database errors, I can't give credence to some of your complaints about system performance, especially where DB access is concerned.

You've moved from GitHub issues (a free service with more limitations) to a hosted JIRA instance, but there's no indication of the number of issues or users. I'd look into the other articles, but your infrastructure has crumpled under the current load. I'll have to revisit this in the future.

JIRA demands a set of dedicated hands to mitigate some of the issues with complexity when it comes to workflows - particularly when there are a bunch of eager, yet disenfranchised hands granted power over implementation-wide workflow, screen and issue configuration parameters. Guidance and change management philosophies apply to JIRA, as well as any other core tool.

Atlassian's hosted JIRA instances are not high-performance. They support up to 2,000 users, but you're paying $1,500 per month for the privilege of a) month-to-month hosting b) managed infrastructure and updates. You can't take the license with you when you leave, and you have zero control over the performance of the instances. This is the tradeoff, and your situation is how it's usually (painfully) realized.

Now, I'm not an Atlassian apologist. I find the lifespan of some of their bugs extremely disappointing, as well as the nature of some of them.

Many of the problems you describe mirror what I see as a consultant providing guidance and rescue to teams who have; inherited a (now critical) skunkworks JIRA installation, operated without a dedicated administrator, outpaced the sizing of their instance, or gone completely crazy with plugins to the extent that they can no longer identify what features are JIRA and which are plugins. Workflows, black arts that they are, have been left to grow as bramble. Team/project/product hierarchies are managed from the bottom up, as opposed to top down, as is the rest of the organization.

These all have remedies, apart from Atlassian's habit of leaving bugs to languish (despite being voted on), which arguably has a remedy of its own.

Limina's sounds like every other frustrated rant I hear from Atlassian users.

My team uses Trello for project management and I couldn't be happier with it. It's very simple by default but you can make complex cards/items if necessary.

I've been thinking about creating a dev focused version of Duet (http://duetapp.com) for a while. Any current Jira users have time to help me figure out what I should add/change to make it a good Jira alternative? I'm a solo developer, so sometimes it's hard to get insight into how teams work on dev projects and some outside input could be very valuable...

Very little known but quite amazing, I’ll point out a tool, as it solves quite a few of the pain points mentioned here. It’s integrated but you can choose what tools to use on a per project basis with a local admin, no need to have a central imposed workflow.

You can choose, per project, which version control to use, GIT, SVN. Which project management method SCRUM, KANBAN, hybrid or waterfall, which code review system, pull requests (in a month) or GERRIT (now).

You can track trace and link pretty much anything in whichever way you want with very flexible trackers. Issue tracking, document versioning, comments you name it, It has templates to get a team started quickly and can be easily adapted later.

It’s proven scalable and fast as it’s already used by companies with more than 17 000 users with a single instance. All is not shiny but it's actively developed with monthly releases.

It’s 100% libre and opensource software with the advantage of having a company fully dedicated to developing it.

If you are wondering what tool I am talking about it’s called Tuleap and you can test it in several ways or install it. If you do, any feedback is welcome. You will find it at https://www.tuleap.org Disclosure I work for the company that is the main contributor of Tuleap.org.

I originally liked Jira, but as I've spent more time with it, I just find it to be a speedbump in my workflow.

I've tried configuring my own workflows, but that is very hard. I can't do things like require log files, or have a good way to guide QA in writing a good bug report. Mandatory fields just become a nuisance.

Sorry all, my apparently terrible web host immediately imploded with the traffic. Trying to resolve now.

JIRA has always felt bloated to me. Of all the ticketing systems I've used professionally, by far and above the best ones were Trac and Redmine (a clone of Trac), which were light, simple, and cut out all the bullshit.

Agreed on all points. Self-hosted alternatives?

Sean from JIRA here. We are having our ShipIt hackathon today so lots of good stuff is going on in the office and there are some cool enhancements to JIRA being demo'd right now. I stepped out for a bit to address some of the comments in Ted's blog.

New tools pop up all the time and I understand the excitement that comes with finding a new one. Often these discoveries come with headlines like this that get the attention of a large audience (or target market) and then they deliver some promotion of the next big thing. That's fine, it is communities like this that propelled JIRA to where it is today and continue to power JIRA every day. Because the community of users powers JIRA, I wanted make sure we shared some of the detail that is relevant to Ted's post.

(apologies for the size of this but my hope is that it gives insight into some of the aspects of JIRA that you may not already use or know about)

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 that you don’t care about so the columns you do care about are bigger. This allows 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.

Organization: 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. (http://blogs.atlassian.com/2016/03/kanban-backlog-jira-softw...)

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 your 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.(https://www.atlassian.com/software/jira/portfolio)

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. https://www.youtube.com/watch?v=K78Nk9kFdb0

-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. https://www.youtube.com/watch?v=F_IIp4uenMw

-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.https://www.youtube.com/watch?v=SRxklyR6fGw

There is always more we want to do and we take feedback seriously. Hopefully, this helps fill in some gaps and address some of the questions raised in this thread.

Cheers, Sean (Disclaimer: I work on JIRA)

I used to hate JIRA. At the present work, it surprises me that I quite like it.

I have thought about this (is my algorithm for liking/hating stuff deficient?), but am not certain if it is because I use a later version of JIRA, or if it is me. Am I less sensitive to bad web UIs?

It is easy to communicate with users and other developers. It keeps the discussion on the tasks in a nice place. It is easy to add queries to other people to call them in to touch a task.

My main theory is that the use case is different; I have more to do with users for the present tasks and the more complex features are less overkill. And I see less of the horrors (more experienced admins).

(Jokes about that this just shows my mental deterioration with advanced age will not be appreciated. :-) )

Like git, we need Linus to come up with totally mindbogglingly simple. I can't tell you how many years we wasted working with stupid/bloated/useless source control systems until git came along.