Jira is a painful to use, especially compared to trello. They own trello now, so I hope they don't mess it up.
If you're using JIRA for stuff that Trello works for, then sure.
What JIRA does and does exceptionally well: grows with your organisation. You can start using JIRA for a simple ticketing system with 3 devs, then continue using it through 100x growth and still use it with multiple product teams, multiple development teams, overlapping projects, CI, code review, wikis, reporting tools, and so on.
If you think that all these tools and sophistication is bullshit, then that's a different conversation -- but a non-negligible number of smart people think that these integrations worth a lot.
JIRA is like Excel or Word -- 80% of people use only 20% of the functionality (or less), but it's a different 20% for all of them. And it's really-really painful to realize that Trello/GH Issues/etc. works great with a slick UI, except that it can't do that single stuff you'd really need because of your special situation.
If you can point me towards someplace visible that is using these tools well, I'm more than happy to be wrong. Every time I've seen them used, they're more like rorschach number generators for management, so I have naturally assumed that my experiences are the normal. That is, of course, a fallacy, so if you can point me to such a paragon of use, I'll be more than happy to check it out.
The strength of JIRA is that if your company suddenly needs a different development flow (whatever it is -- new tooling, new workflow, more teams, awkward regulatory requirements etc.) then you can stay with JIRA because whatever you want to do will be possible with JIRA.
(Uh, I sound like an Atlassian shill, even though I dislike the lagginess of their UI and also how they handle Bitbucket. :) )
This actually seems to me to be the biggest problem with JIRA... JIRA allows for the creation of arcane processes that very easily become burdensome because JIRA is very loose in its opinions. And, on top of that, the management of that process also often becomes a burden for the same reason...
And you're also stuck carrying around all the features you don't use...
Works as a general rule, too.
But I think this does get to the core issue with JIRA. Whether you "like" JIRA or not is more a reflection of your organization than it is a reflection of JIRA as a tool.
The agency I work at uses these tools together with ovur clients, as well as internally on different levels.
We have an internal project were we are just using tasks, subtasks with 3 states in a team of 9 in three to four locations. And we have a client, being served with about 100 people in different teams working on multiple projects, spanning multiple locations. Here we use the same tool. In one case with just a basic setup. One a 'little bit' more elaborate and customized...
And, of course, it's configurable, so any local installation of Jira can be tweaked in such a way that it's a pain in the ass...or not.
I've worked places where there was a high amount of incoming work, and no tracking, and it wasn't healthy. Lots of "squeakiest wheel", "who is working on this?" and other issues.
I am not sure who the 'management' would be in their case.
Just throwing something out there... But I wonder what the spread of these "smart" people is across "development" and "management"? The parent comment seems related to this...
> JIRA is like Excel or Word -- 80% of people use only 20% of the functionality (or less), but it's a different 20% for all of them. And it's really-really painful to realize that Trello/GH Issues/etc. works great with a slick UI, except that it can't do that single stuff you'd really need because of your special situation.
Also, just throwing something else out there... But I wonder, at what point, do we stop building tools that can work for 99% of the use cases and start actually having opinions on which specific use cases are "good" or should be encouraged? Because, like some of the other comments have said, a lot of those workflows that "only use 20% of the functionality" aren't exactly appealing.
The "tool" doesn't need to be overly "opinionated" just like a programming language, I want a tool to be flexible. It's my responsibility as the architect to constrain the tool/language for my environment.
Now, if there was a way to grow its user interface along with the organization's growth, it would be fantastic.
I feel like, as an industry, we should be moving beyond that at some point.
Its put in with reluctance rather than enthusiasm.
And to be honest, it's a process tool. Dealing with processes is boring.
Jira is better than bugzilla and trac. And much better than some tools, constructed from manure, from big IT companies and sold for very high price tags.
It's sad to me that they lost momentum. I think they got stuck trying to overcome tech debt and bug fixes and feature requests started to pile up.
From time to time I keep an eye on CommonMark implementations and fantasize about writing an MVP to replicate parts of Trac by composing existing tools. Unfortunately there are like 5 other things I'd rather do with my free time.
I've seen one dev excited - the one who tested other tools and picked Jira because it checked off on all the "features" needed. It really did handle the arcane and complicated workflow we had. But besides that few liked it, though it was a mix of hating the slow and unresponsive UI and hating the arcane process.
Instead of adopting a sound process, customers will take an overly complicated business process and make the tool conform to this process. And please note that in this cases how you manage your code workflow is, in fact, the business process.
Any tool will struggle - often it's the process that's cumbersome and not the tools.
For me, I'd love to have a flexible-enough tool for small to medium sized orgs that encourages a modern lightweight process and discourages ad-hoc process sillyness. Sometimes having a tool gently encourage better practices among all participants is a useful thing.
* The idea of the "Atlassian Ecosystem", in that buying more of their services seems to work better.
* On-premise for most of their tools
* Pricing. For example, Bitbucket Server - $26,400 for 500-1000 users /year [1]. GitHub Enterprise - $2,500 per 10 users / year [2]. Self-hosted GitLab - $39 or $199 per user / year (Starter compared to Enterprise Edition Premium package) [3]. If at a 1000 users, that is $26,400 compared to $250,000 or $39,000/$200,000.
* "Other big companies use them"
* "Reporting and metrics"
* "There is a plugin for that"
But, I and most of the other developers I have worked with hate every single Atlassian product we use. JIRA eventually turns into a micromanagement tool with all of the customization people think they want. People seem to think that because it is customizable, it will solve their problems. It always seems to take up more time and resources to try and bend their tools to do anything useful than it is to just say, "well, I guess we don't really need that".
[1]: https://www.atlassian.com/licensing/bitbucket-server
https://bitbucket.org/product/pricing?tab=host-in-the-cloud https://github.com/pricing
Can you expand on that? I've never seen a manager use it well. They use it to generate numbers for their reports for the people they report to, and it doesn't tend to matter what those numbers or reports actually represent. For example, it's very easy for process to make velocity numbers complete hogwash.
Basically, as far as I can tell, it's great and being able to tell you what you want to hear, and not very good at providing usable insights that increases productivity, but people don't notice because they're hearing what they want to hear.
For my money, the #1 benefit to scrum is improved visibility to stakeholders and any productivity gains to the dev are the result of them being able to work on things in the correct priority order due mainly to benefit #1.
One thing I definitely don't have is any managers living in it. It has all kinds of (useless, IMHO) reports it can spit out, but we don't spit them out, other one for time tracking some particularly-tagged issues (for the SR&ED tax credit program).
What is really awesome though is looking back through issues (and in general, JQL). For example, finding any re-opened bugs:
type = bug and (status changed to reopened after 2017-01-01) and project in (PROD1, PROD2)
project = PROD1 and fixVersion = "2.0" and affectsVersion != "2.0"
This is very anecdotal. To see JIRA used well, you need both management which is willing to invest the time and effort necessary to learn the ins and outs of configuring JIRA, as well as competent and flexible stewardship by the admin team to enable desired configuration in a way which fits in with the rest of the instance and doesn't pollute it. If you pay attention to recent JIRA releases, Atlassian is trying to enable management to make the changes it wants to make without resulting in global pollution, but either way, you still need management to personally buy in.
I've seen everything from managers who refuse to customize workflows beyond "todo-in progress-done" to managers who use post-it notes on the wall for their "real" agile board, and then copy the changes by hand into JIRA issues to communicate status up the ladder. If your company's management isn't buying in, your company needs to either replace the managers or replace the tool, instead of trying to fit round pegs into square holes.
IMHO If you are a small startup and can be self disciplined, you don't need Jira. It is more for enterprise setup where accountability/responsibility has to be generally enforced.
I think this is some kind of natural law: any sufficiently old enterprise system tends towards becoming an ad-hoc, bug-ridden, poorly specified workflow engine.
Those reports are not generally being used to make sensible decisions, but they make management feel more in the know and in control and thats what really drives sales.
Personally, I don't mind JIRA and the Atlassian toolset as they are so much better than what we used to use in the old days.
Jenkins comes to mind, Jira of course, and just about any other Java project's website still looks like it is from the 90s.
Also, all the big internet companies use Java, basically. You're using Google, Amazon, Twitter, Netflix, etc. products and you're using Java. Do you also hate those? :)
Furthermore, Java is mostly server side at this point so I'm not sure your UI complaint is really valid...
Other tools, fogbugz, trello, etc are very good at what they do.
Invariably though when you get enough projects that are complex enough (not always big), JIRA has been the only thing that could take a bite out of managing the details like few others.
JIRA also can be greatly simplified to use but most users don't do this. The JIRA core offering is what I recommend to folks. JIRA is heavier for dealing with heavier projects.
On the flip side. Having a search engine of every issue and decision, be it design, system, implementation, roll out ticket for every project in a company is second to none.
I recently assisted a client in their systems design and growth from from 0 to 50m revenue in 4 years. It feels strange and wondeful to have every decision made in one searchable place, on one time line for every major piece of software or system implemented for them.
Most start from scratch projects can be nicely managed in Trello et al.
Generic search alone isn't the feature, or the benefit. None of those options listed have a deep enough search. GitLab and GitHub aren't a project manager - projects that are manageable in Git* likely aren't complex, or enterprise grade.
I have tried nearly every product in this arena as well over 20 yrs of dev in different types and sizes of projects. JIRA begrudgingly is my neccesary evil. I hear nice things about Pivotal Tracker as well, just didn't reach my sphere of folks when I was looking.
I can see the appeal of that. That is a killer feature for me. My team currently runs what I find to be a pretty lean and clean workflow using Trello, Github (for source control and issues), and Wikimedia for documentation. (Oh, and can't forget Outlook for release scheduling.) Having all of that in one place would make life easier.
On the other hand, not having a monolithic service handling everything has forced us to pay attention to our workflows and practices and keep them sharp.
But the team is small. If we grew or had to manage more projects across multiple teams, this would be really valuable.
I used FogBugz for almost a decade until the most complex projects I was working on dragged me into JIRA. I miss FogBugz' email first interface.
My Current stack is JIRA/Confluence on demand, the integration in the WIKI is simply too good to overlook. For product roadmapping I use Aha.io integrated into JIRA.. it's so far a more capable product than JIRA Portfolio, JIRA portfolio doesn't go high level enough. Harvest in the mix for easy time tracking.
The investment of time in integrating projects between Aha and JIRA so far has been a big payoff. We can literally start noodling with ideas high level, and as soon as those ideas cross the line into an epic, we have the sprint ready to go and automatically created in JIRA.
While it wasn't as smooth, the incredible detail we can manage things that need it, while leaving other simple items to hop through the steps that aren't needed was invaluable.
Processes (agile) and UIs (kanban) have been much more standardized in software project management and only now does it seem like some companies are coming up to give you that 90% out of the book with 10% the overhead/ management. Pivotal Tracker came close.. Clubhouse.io is the one I've seen doing it best.
They have quite different DNA. Tracker grew out of Pivotal Labs and it is mostly molded to how Labs and R&D teams do their daily and weekly work. To me it seemed constricted and limited until I came to work at Pivotal; now it makes sense.
Disclosure: I'm an Atlassian employee, but I had these opinions before I started.
Have never been able to use trello effectively with any clients. It's simply too open-ended on its own. "Issue trackers" (like Jira) have some semblance of workflow predefined, and act as a decent guide for people who are not "project managers" to still bring some degree of order/structure, with the benefit that that structure was actually defined by someone else who thought about data/structure/flow/etc.