Hacker News new | past | comments | ask | show | jobs | submit login
Why I finally ditched Jira (liminastudio.com)
104 points by virgil_disgr4ce on Sept 9, 2016 | hide | past | favorite | 114 comments

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.

Goodness yes. JIRA has become way too many things to way too many people. It's got a feature for everything, which means it's good at nothing. I'd rather just go back to bugzilla at this point.

The agile stuff in particular feels like a bolt-on. Its obvious that JIRA grew up from a simple bug tracker to a complete software development workflow engine. The pain points of its growth and add-ons are frustratingly obvious. It really needs a reboot.

I feel like Atlassian products are vulnerable to be picked off. There's going to be something that kicks it off its pedestal soon. Good riddance.

Agreed. It feels like Atlasssian never met a feature request that they didn't say "no" to.

Unfortunately, most of the tools out there don't scale well, so most teams reach the point where Jira is the only reasonable choice.

(Full disclosure, building https://clubhouse.io address this problem.)

They only say "no" to something you (think you) really need at this moment :) Say, https://jira.atlassian.com/browse/JRA-4446 "Sub-issues should be able to contain their own sub-issues" -- #6 on the list of top voted for.

To be fair, they did say "no" to this. (After 11 years. :-) )

Actually Stash issue's were handled badly. Some issue's were delayed for better "integration" with jira. unfortunatly these issue's were way more important.

We have been very happy with Clubhouse. Still missing some templating features we'd like to see and it could probably use something along the lines of Themes, but it has been a good fit for us.

Me too. Granted our team is tiny, but Clubhouse is quite snappy. And built on Clojure!

"Something along the line of themes" is coming soon...


There are at least 5,000 for JIRA alone: https://jira.atlassian.com/browse/JRA-161?jql=project%20%3D%...

Perhaps you confused "it feels like" (implying that it feels bloated with many esoteric and/or generally useless features) with the statement "there's literally never been a feature that they've said no to" which is something else entirely and what you seem to be disproving here.

In that case, does it really feel like they've said no to any enhancement request that's come through?

From my experience, and those who have watched issues for ten-odd years, I'd say the opposite is true, but I'm not working on a competing product.

Disclaimer: I work on JIRA Software

"Biggest issue I have with Jira is how it's trying to be the everything tool for all processes and procedures"

JIRA didn't try to be a universal tool for all processes and procedures, but it happened to spread from the development team into other parts of organisations due to it's flexibility. Of course that flexibility comes at a cost the experience to the end-user is controlled by the administrators.

What is the alternative? A more opinionated tool could potentially get a specific task done better. The problem is that you will need 2, 3 or more separate, more opinionated tools to cater for the specific use-cases. These tools will have to be maintained and probably won't integrate very well, making collaboration between different departments a lot more difficult. That's exactly what JIRA tries to solve, help your teams collaborate.

Could Atlassian be more opinionated. Absolutely. Being opinionated doesn't necessarily mean that we need to limit the flexibility of JIRA. We can do a much better job at optimising for specific use-cases and guiding people towards best practices, while still allowing customisations where desired. We've started this effort last year by introducing JIRA products aimed at specific use-cases. Take JIRA Software for example, it's aimed at Software teams and has specific features like Scrum, Kanban boards, sprints and releases that are specific to software teams. If you aren't a software team, you can just use JIRA Core and you don't need to worry about what Scrum even means.

There is a lot more we can do to make the simple things simpler, and it's a big focus area for us. We won't enforce limits on the number of fields you can add, but we are looking at giving project administrators a lot more autonomy around how their projects are configured. We can't stop the QA checkbox from appearing if somebody really wants it there, but we can provide the guidance and tools to make the experience better for everyone.

Happy to answer any questions you may have.

Just a counter-point: The non-dev, non-qa people have to get their data from somewhere. Why not consider the issue tracker the "source of truth" for information about the issues that affect the project? The alternatives are:

1. maintain parallel excel (or whatever) sheets and have all these different managers manually bugging the developers and qa people constantly to keep it up-to-date, or

2. stand up parallel systems to track each of these things with varying levels of integration, and as a developer you now need to remember to both close the issue in your bug tracker AND update this project management dashboard AND update the security status tracker AND add a ticket to another system to get the end user documentation updated AND on and on...

When you've worked with that kind of system, you start to long for the simplicity of another field in the issue tracker.

Exactly why I described it as the "Salesforce of project management." shudder

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.

The post mentioned that they are using the cloud version (that is, hosted by Atlassian themselves).

I also use the cloud version and find it painfully slow.

We have probably less than 200 issues logged at my company. We have 3 users for ourselves, and another 3 for customers to report issues. It's a second or two for every single bit of navigation on the site, and absolutely ages for a search.

So, have Atlassian configured their own software badly?

> The post mentioned that they are using the cloud version (that is, hosted by Atlassian themselves)

The post also mentions that they had it installed. I'm not sure which line to believe more...

> So, have Atlassian configured their own software badly?

It.. sounds like they do?

We have thousands of issues across over a dozen projects, and 50+ users (probably 20 or so concurrent at peak usage.)

The only lag I've ever seen is a few seconds to do a complex JQL search. Otherwise it's milliseconds between pages.

We are working hard on performance and have some major work underway to improve this.

Glad to hear it.

Thanks for replying.

> we don't seem to have any of the problems described in this article...

You may want to more carefully read said article:

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

Ahh, now it makes more sense, especially since the article said they was running on Jira's hosted Cloud version. ;)

> Bugs filed against Jira are done in Jira.

Perhaps this is why the mentioned bug has been outstanding for five years ;)

I guess he just threw me with this line: > ...my company already had JIRA installed and I figured that would be good enough.

Which made me think it was an installation instead of the cloud based version.

He mentions he's using the cloud-hosted version so I don't think it's the version / hardware that's the problem.

yeah because upgrading JIRA is a real pleasure. ;)

Some great upgrade news will be coming at Summit in October. You will like this.

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.

> try searching for something as simple as all tickets to which you added a comment in the last week...no chance

That's actually a crazy complicated query if you think about. Not so much from a straight sequel side, but how exactly would you build a friendly UI that lets you specify the conditions that would give you the resulting query? Everyone here is bashing on JIRA UI for being too complicated and trying to do to much, but then you have people wanting features like this.

If it is too complicated but can't do this, then maybe it is complicated in a wrong way.

Second, "tickets to which you added a comment in the last week" in other words are "active tickets for a week" or more shortly "tickets related to me", which seems to be pretty useful for, e.g., a welcome screen for a developer/manager/whatever. One doesn't look at new tickets each 15 minutes, idk why all darned trackers show that after login.

Well I have no idea how they store their data, but if it was straight T-SQL and assuming a table for tickets, a table for comments, and a table linking the two (typical way to implemente 1-to-M relationships) something like (pseudo SQL)

SELECT * FROM tickets JOIN ticketsToComments on tickets.ID = ticketsToComments.ticket_ID join comments on ticketsToComments.comment_ID = comments.ID JOIN autor on comments.autor_ID = autor.ID where autor_ID = me and tickets.date < 1 week

It's not rocket science

> Well I have no idea how they store their data, but if it was straight T-SQL and assuming a table for tickets, a table for comments, and a table linking the two (typical way to implemente 1-to-M relationships)

Wouldn't 1:M just be a typical FK relationship, a join table is only needed for either M:N relationships or relationships that have additional attributes belonging to the relationship rather than either of the joined tables.

Yes you are right, it was late at night :-) That makes it even simpler, removing one join...

SELECT * FROM tickets JOIN comments on comments.ticket_ID = ticket.ID JOIN autor on comments.autor_ID = autor.ID where autor_ID = me and tickets.date < 1 week

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 one of a small handful of JIRA/other atlassian app admins at my company, yeah, this.

The problem with pretty much anything Atlassian makes is that it's too easy to setup, in that you can have a working, but non-performant, awful to use system without much hassle.

Best advice I can give here is talk to your users. Find out what they think sucks about your setup, and then actually work on those things.

Do you really need 20 custom fields filled in by hand, or could that be automated?

Do your PMs have any idea how the query syntax works? (Send them to class for this - seriously!)

Does your workflow really need 19 disparate steps each with their own triggers and conditions? Beyond a certain point, you can't even reason about the system anymore. Someone, somewhere is going to have to compromise.

The more capabilities people have the opportunities they have to be great or be confused. It is a tough balance but generally speaking the flexibility of JIRA lets teams do some amazing things. We need to always we making sure it is harder for people to make mistakes but also need to make sure that our core users can have the flexibility they demand.

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/

Problem with Zenhub is that it's tied to github. It would be much better if it were independent of any git hosting platform. If you make Zenhub run against Stash or Gitlab, then we're talking about something useful to markets that can't/don't use github.

Love Zenhub. Hate Jira. I think many PMs forget that the first word in project management is PROJECT. They get it backwards and we end up with process for process sake rather than a process that complements how developers actually develop.

That's why we highly value flexibility on JIRA. Forcing a terrible workflow on people is a sin. At the same time, we've always gotta help keep people from over complicating things.

At a cursory glance, it seems to be GitHub specific. Any plans for BitBucket or GitLab support?

Right now we are focused on getting the experience right in GitHub, but I agree that an ultimate solution must allow teams the choice of which source control system they want to use.

We get lots of feature requests for GitLab and BitBucket support so those are two likely points to integrate with next.

As a dev I don't mind Jira that much (I try to use it the most basic way possible) but I often get remarks, especially during daily scrum meetings, that I don't update my tickets enough.

Well OK but at that point it is kind of redundant with DSMs anyway ... but I guess it fulfills product owners micro-management fantasy land.

One thing that we've built[1] is a way to hook a Branch to a story (by including the story ID in the branch name, which also starts it) which causes all of the commits on the branch to feed into the ticket and allows you to use Pull Requests and Merges to change the state (i.e. "Open Pull Request -> Move to Ready for Review).

Ticket update overhead sucks.

[1] https://clubhouse.zendesk.com/hc/en-us/articles/207540323-Us...

Can we please stop prefixing "Zen-" onto things as a sort of trendy, cool "hey, it's well designed and simple" signifier?

It's borderline racist. Would you call a project management tool "Jewhub" or "Catholichub"?

> It's borderline racist

No, its not. Zen isn't a race (or even ethnicity).

Its perhaps religiously insensitive to Zen Buddhists; I'm really not sure how they tend to view the fact that -- largely through non-religious philosophical works directly influenced from contact with, though not necessarily relaying the teachings of, Zen Buddhism -- rather than, e.g., hostile stereotyping of Zen Buddhism -- the term "zen" has taken on a more general sense of simplicity and minimalism in popular culture, which is actually what the name directly relates to.

Yes, it is. Zen as such is a religion and philosophy from Japan; it is intrinsically Japanese, by definition, just as Judaism is by definition intrinsically of the Hebrew ethnicity.

I am aware of the use the term has taken on in popular culture, divorced from its original context -- that's precisely what I'm complaining about.

This trend is nothing more than ongoing cultural appropriation of exotic cachet and a watered-down stereotyped design aestheic from a faraway foreign ethnicity, in order to seem cool and sophisticated to other westerners. Websites labeled Zenwhatever have nothing to do with actual zen. It's a philosophical blackface minstrel show.

That the stereotypes being promoted about an ethno-religious identity seem to be positive and flattering is irrelevant. Few people would call their accounting software "Jewbook" to trade on a supposedly positive and flattering image of Jews as prudent financial managers -- yet "Zenefits" is supposedly fine.

Indeed, 50 or 100 years ago, many people widely used the word "Jew" as an adjective in a positive and flattering sense related to "having business acumen" or "being a good negotiator," and when challenged offered very similar defenses to the one you just offered, about how "jew" had by then become a generic word for something good, divorced of its original context, and not a religious stereotype or insult in any sense.

In Japanese culture, incidentally, Zen is most typically associated with Japanese racial superiority ideology and far-right wing militarism. How ironic considering its cachet among young, cool progressive types in the west!

Actually wikipedia says that Zen is originally Chinese https://en.wikipedia.org/wiki/Zen

if you dig further, it is indian: Dhyana -> Chan(na) -> Zen.

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.

Can you say more? What makes the difference between correct and incorrect instrumentation? What are the powerful features that it has that the others don't?

In short, how do we make a Jira install into something powerful and useful?

Like you do with all 'highly-configurable' tools. You invest time/money into issue tracking expertise, learn hard what you really need, learn the instrument, google what tweaks can move it closer to your needs, and voila, you are ready to write your own 'highly-configurable' tool and win the industry (and clear some expenses).

That's full opposite of a Product.

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.

Another pro: waffle.io is free (as in free beer)

Plus waffle.io has support for putting several repos on one board: https://help.waffle.io/hc/en-us/articles/225548707-How-do-I-...

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

We use VersionOne and it is the most painful thing ever. Even worse is I think ours is a custom installation with even more pointless metrics that we have to track.

Nothing would ever get entered if not for the scrum master yelling at use to "burn your hours" multiple times a day. All of this gets reported up, in complete violation of scrum. The stories and small amount of documentation associated with them near no relation to what we work on and we aren't going to update them because VersionOne is so painfully slow and counterintuitive.

Something like 90% of a scrum masters job here is maintaining VersionOne. If you have to dedicate one person per team to a tool, maybe that tool isn't saving you any time or money.

HP (formerly Mercury) Quality Center seems designed to sell to managers or to sell professional services for life rather than for someone using it daily to actually get anything accomplished. So it's just like most enterprise software I guess.

Back in the days when my team used QC, we'd refer to MI products as "QA products without QA done on them."

Exactly. It always amazes me when I come across articles articles or comments about Jira being so terrible. Try using Bugzilla for project management, or Gemini by Countersoft, VersionOne, OnTrack... There are some truly horrible products out there, but they show the right metrics and graphs to the C-suite people that pay for them.

At one point after we lost our project manager I said fuck you to the managers and just used Trello boards. It took them months to realize the graphs for my team weren't changing.

We're on servicenow. I begged to use the atlassian stack over that platform.

Too late. The choice was made by those who'd barely use the tool.

hating JIRA is a first-world-problem for people on servicenow. it's like hating how starbucks baristas ask you too many questions

Hi. We use both. VersionOne for sprint planning/tracking and Jira for bug tracking.

Oh, and the VersionOne stories all link back to Jira which contains the original story for the functionality.

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/

We switched from

  Bitbucket-> Jira -> Bitbucket -> Youtrack
We use Bitbucket for SCM hosting because .. yes we are still on mercurial (and yes we still love it) but mainly because Bitbucket allows unlimited repositories which is far far better for our workflow (Java + Maven). It is important to understand that we have a lot of projects each in their own repository as I still firmly believe this is the right way to do things. I guess users of github private must do the giant repository thing.

Bitbuckets issue tracking was almost good enough but because as mentioned earlier we have lots of projects however business wise those projects map to a few singular products. Many SCM+issue management including Bitbucket only allow one repository. That is checkins from different repositories don't get picked up by some parent aggregation project.

So Atlassian pushed us on to Jira... what an epic failure that was. The cloud hosting was so slow and was generally overly complicated.

Finally we moved to youtrack. It is dorky but so awesome. It is the issue tracker for developers. Is a great product but its integration pieces are sort of buggy. For example bitbucket integration no longer works because of 2FA (reminds me I need to check if they have fixed it now).

It is pretty sad because we are essentially loyal Atlassian customers (Bitbucket) and yet we were forced to moved to another product. I really wish they would just improve Bitbucket's issue tracking as I still like having the code close to the issue management.

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.

Agile was supposed to be a mindset without any enforced tools or practices. Use Jira or post it notes or whatever works for you with plenty of experimentation.

Unfortunately it is easier to force a tool on people and call it agile than change an organization.

+1 for "Individuals and interactions over processes and tools"

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?

We are having great success with Phabricator - https://www.phacility.com/

The purposeful mispelling of 'f' as 'ph' is already driving me nuts.

I'm personally LOVING Phabricator as a JIRA alternative. It provides me with all the things I need from JIRA but doesn't pack in as much cruft.

I run a small company so I don't need the more enterprise features of the Atlassian tools, but damn it's a great alternative.

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. :-) )

I've heard that Jira is such a Swiss Army knife that your experience with it is extremely influenced by how it is configured. If it was poorly thought out and configured then you will hate it.

That's my take as well: the good/bad thing about systems like Jira is that they're so customizable and will thus increasingly mirror your underlying organizational culture. In a well-run organization that's great but people who work somewhere which is struggling might actually find an odd advantage to something like GitHub Issues in the sense that the lack of customization prevents the otherwise inevitable accretion of complexity.

the otherwise inevitable accretion of complexity.

Oh wow, that's fantastic - can I license that? :)

Feel free!

> your experience with it is extremely influenced by how it is configured

When I hear something like that about a product, my first instinct is to run away. I already know plenty of programming languages, I do not need a Turing complete interpreter with an arcane language added to it.

I'd say that's probably a fair assessment. I'd also wager that on-premise vs. cloud hosted (given that two of the points of the original story talked about speed). Though you could group that into configuration.

OK, I'll buy that... it is not me, it is the administrator(s).

Maybe you been stuck in it so long that now you like it lol


Isn't there another name for this syndrome that would fit better with this particular situation?

Stockholm Syndrome?

I believe there is, but this was the closest I could find :(

That's the one!

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

I've used it at several places and had the same experience. The one caveat I have is that all of those teams were using the full Atlassian suite which was actually really nice.

And we were using EVERYTHING:







The integration with all of these made those teams really efficient at what we did. Not sure if this had anything to do with how much easier or better JIRA worked, but I never had an issue with it.

Add Confluence to that list. Some integrations with JIRA are very nice, such as having a table of issues and their statuses on a wiki page is the cat's meow.

I have a meh-hate relationship with Confluence markdown, wishing for straight mediawiki. Another issue is that many of the plugins that would improve your life, such as "plain html please", have to be purchased and are expensive.

It supports Markdown? I don't see any way to escape the WYSIWYG editor.

On a Mac press ⌘-SHIFT D or select 'Insert more content' and 'Markup'.

Is there a way to edit a whole page that way?

edit: looks like that's just a way to insert a single bit of content, not edit existing content :/

I can't stand the sidebar.

[ toggles it

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.

Have you ever tried "man git"?

git is bloated, and certainly anything but simple. It's also arguably stupid in a lot of ways.

git is fast, though, and that's one of the main reasons it won over other version control systems which were a lot more elegant and easy to use.

>git is bloated, and certainly anything but simple. It's also arguably stupid in a lot of ways.

Amen. I have to confess that I actually prefer Mercurial to git; it just feels simpler to use.

I agree. A lot of that comes from the fact that Mercurial's UI is basically "SVN, but as a DVCS", and I like that. I still use Mercurial for my personal projects (using my Linode to push backups to).

Then again, I'm also of the heretical position that if you don't need the distributed parts of a DVCS, you should use SVN.

I agree. Bitkeeper actually has a much better command line user interface and is more intuitive, but free and fast is hard to pass up.

Magit puts an extremely intuitive UI on top of it, and has made git a pleasure to use again, for me.

I use Magit myself and love it, but it still has a truckload of commands, and to avoid shooting yourself in the foot you have to know what they do (crack open "man git" again), which ones to use and when to use them, and often even how git works in detail under the hood.

Magit certainly makes working with git easier and faster, and combined with the power of emacs it makes for a very powerful tool. But it has still been very far from simple or elegant for me, once you get beyond the basics of what git can do.

I personally see this as a design problem with git, which a tool like Magit can mitigate but not solve.

Are you referring to darcs?

Git is quite elegant underneath the terrible UI.

No, I was referring to bzr (formerly called "Bazaar").

There was a really good talk given by one of its lead developers about why it failed, called "Remedies for Frustration".[1]

It's well worth reading (make sure to read the slide notes, not just the slides themselves!) and has some great lessons about how the aversion to "premature optimization" can lead to the ruin of a product (in this case, of bzr, which had an elegant UI, but was too slow to compete with git).

[1] - https://docs.google.com/presentation/d/1awg1CHM1w128iOBp_JOx...

I don't think git won over bzr just because of speed. It was also much more powerful in meaningful ways (`git reset <hash>`, `git rebase -i`, ...) very early on.

Also, the internal git model is elegant. Having used bzr for years, I never understood its internal model.

git = Asana

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact