10 ms·

Why I finally ditched Jira

laurent123456 10y ago
Google Cache: http://webcache.googleusercontent.com/search?q=cache:http://log.liminastudio.com/writing/commentary/why-i-finally-ditched-jira http://webcache.googleusercontent.com/search?q=cache:http://...
didsomeonesay 10y ago
Agreed on all points. Self-hosted alternatives?
- mattvot 10y ago
  We are having great success with Phabricator - https://www.phacility.com/ https://www.phacility.com/
  - JohnLeTigre 10y ago
    The purposeful mispelling of 'f' as 'ph' is already driving me nuts.
  - tlackemann 10y ago
    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.
berntb 10y ago
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. :-) )
- rblatz 10y ago
  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.
  - swsieber 10y ago
    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.
  - berntb 10y ago
    OK, I'll buy that... it is not me, it is the administrator(s).
  - acdha 10y ago
    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.
    - _hyn3 10y ago
      the otherwise inevitable accretion of complexity. Oh wow, that's fantastic - can I license that? :)
      - acdha 10y ago
        Feel free!
  - marcosdumay 10y ago
    > 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.
ctrl-j 10y ago
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.
- yalooze 10y ago
  He mentions he's using the cloud-hosted version so I don't think it's the version / hardware that's the problem.
- GlennS 10y ago
  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?
  - ctrl-j 10y ago
    > 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.
  - seanjregan 10y ago
    We are working hard on performance and have some major work underway to improve this.
sickbeard 10y ago
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.
- pmoriarty 10y ago
  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.
  - Peaker 10y ago
    Are you referring to darcs? Git is quite elegant underneath the terrible UI.
    - pmoriarty 10y ago
      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_JOxE2DgHfywBeyjDe2bkx1vfVQ https://docs.google.com/presentation/d/1awg1CHM1w128iOBp_JOx...
      - Peaker 10y ago
        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.
  - ldiracdelta 10y ago
Shank 10y ago
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.
bitwize 10y ago
O HAI. You think Jira is bad? Let me introduce you to VersionOne.
- devonkim 10y ago
  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.
  - lowmagnet 10y ago
    Back in the days when my team used QC, we'd refer to MI products as "QA products without QA done on them."
- jobu 10y ago
  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.
- strictnein 10y ago
  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.
- quantumhobbit 10y ago
  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.
gotofritz 10y ago
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.
- locopati 10y ago
  Install the Script Runner Plugin: issueFunction in commented("by username after -7d")
- mikey_p 10y ago
  > 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.
  - wruza 10y ago
    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.
  - gotofritz 10y ago
    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
virgil_disgr4ce 10y ago
Sorry all, my apparently terrible web host immediately imploded with the traffic. Trying to resolve now.
ma138 10y ago
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/ https://www.zenhub.com/
- briandear 10y ago
  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.
  - seanjregan 10y ago
    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.
- GrumpyYoungMan 10y ago
  At a cursory glance, it seems to be GitHub specific. Any plans for BitBucket or GitLab support?
  - ma138 10y ago
    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.
zbjornson 10y ago
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 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.
- guaka 10y ago
  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-add-multiple-repositories-to-a-single-board- https://help.waffle.io/hc/en-us/articles/225548707-How-do-I-...
Yhippa 10y ago
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.
- quantumhobbit 10y ago
  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.
  - ibuchanan 10y ago
    +1 for "Individuals and interactions over processes and tools"
mxuribe 10y ago
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/ https://www.jetbrains.com/youtrack/
- agentgt 10y ago
  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.
raverbashing 10y ago
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.
deleted 10y ago
[deleted]
amyjess 10y ago
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.
strictnein 10y ago
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.
- taftster 10y ago
  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.
  - kschrader 10y ago
    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 https://clubhouse.io address this problem.)
    - jaxb 10y ago
      They only say "no" to something you (think you) really need at this moment :) Say, https://jira.atlassian.com/browse/JRA-4446 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.
pritianka 10y ago
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.
- Periodic 10y ago
  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?
  - wruza 10y ago
    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.
dudul 10y ago
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.
23andwalnut 10y ago
I've been thinking about creating a dev focused version of Duet (http://duetapp.com 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...
itomato 10y ago
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.
blahshaw 10y ago
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.
mikey_p 10y ago
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.
- seanjregan 10y ago
  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.
- Karunamon 10y ago
  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.
andrewl 10y ago
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.
seanjregan 10y ago
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-software/ 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 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 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 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 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)
gwbas1c 10y ago
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.
matemaz 10y ago
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 https://www.tuleap.org Disclosure I work for the company that is the main contributor of Tuleap.org.

Google Cache: http://webcache.googleusercontent.com/search?q=cache:http://log.liminastudio.com/writing/commentary/why-i-finally-ditched-jira http://webcache.googleusercontent.com/search?q=cache:http://...

didsomeonesay 10y ago

Agreed on all points. Self-hosted alternatives?

mattvot 10y ago
We are having great success with Phabricator - https://www.phacility.com/ https://www.phacility.com/
- JohnLeTigre 10y ago
  The purposeful mispelling of 'f' as 'ph' is already driving me nuts.
- tlackemann 10y ago
  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.

berntb 10y ago

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

rblatz 10y ago
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.
- swsieber 10y ago
  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.
- berntb 10y ago
  OK, I'll buy that... it is not me, it is the administrator(s).
- acdha 10y ago
  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.
  - _hyn3 10y ago
    the otherwise inevitable accretion of complexity. Oh wow, that's fantastic - can I license that? :)
    - acdha 10y ago
      Feel free!
- marcosdumay 10y ago
  > 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.

ctrl-j 10y ago

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.

yalooze 10y ago
He mentions he's using the cloud-hosted version so I don't think it's the version / hardware that's the problem.
GlennS 10y ago
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?
- ctrl-j 10y ago
  > 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.
- seanjregan 10y ago
  We are working hard on performance and have some major work underway to improve this.

sickbeard 10y ago

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.

pmoriarty 10y ago
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.
- Peaker 10y ago
  Are you referring to darcs? Git is quite elegant underneath the terrible UI.
  - pmoriarty 10y ago
    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_JOxE2DgHfywBeyjDe2bkx1vfVQ https://docs.google.com/presentation/d/1awg1CHM1w128iOBp_JOx...
    - Peaker 10y ago
      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.
- ldiracdelta 10y ago

Shank 10y ago

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.

bitwize 10y ago

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

devonkim 10y ago
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.
- lowmagnet 10y ago
  Back in the days when my team used QC, we'd refer to MI products as "QA products without QA done on them."
jobu 10y ago
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.
strictnein 10y ago
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.
quantumhobbit 10y ago
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.

gotofritz 10y ago

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.

locopati 10y ago
Install the Script Runner Plugin: issueFunction in commented("by username after -7d")
mikey_p 10y ago
> 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.
- wruza 10y ago
  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.
- gotofritz 10y ago
  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

virgil_disgr4ce 10y ago

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

ma138 10y ago

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/ https://www.zenhub.com/

briandear 10y ago
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.
- seanjregan 10y ago
  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.
GrumpyYoungMan 10y ago
At a cursory glance, it seems to be GitHub specific. Any plans for BitBucket or GitLab support?
- ma138 10y ago
  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.

zbjornson 10y ago

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

guaka 10y ago
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-add-multiple-repositories-to-a-single-board- https://help.waffle.io/hc/en-us/articles/225548707-How-do-I-...

Yhippa 10y ago

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.

quantumhobbit 10y ago
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.
- ibuchanan 10y ago
  +1 for "Individuals and interactions over processes and tools"

mxuribe 10y ago

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/ https://www.jetbrains.com/youtrack/

agentgt 10y ago
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.

raverbashing 10y ago

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.

deleted 10y ago

[deleted]

amyjess 10y ago

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.

strictnein 10y ago

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.

taftster 10y ago
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.
- kschrader 10y ago
  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 https://clubhouse.io address this problem.)
  - jaxb 10y ago
    They only say "no" to something you (think you) really need at this moment :) Say, https://jira.atlassian.com/browse/JRA-4446 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.

pritianka 10y ago

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.

Periodic 10y ago
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?
- wruza 10y ago
  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.

dudul 10y ago

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.

23andwalnut 10y ago

I've been thinking about creating a dev focused version of Duet (http://duetapp.com 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...

itomato 10y ago

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.

blahshaw 10y ago

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.

mikey_p 10y ago

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.

seanjregan 10y ago
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.
Karunamon 10y ago
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.

andrewl 10y ago

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.

seanjregan 10y ago

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-software/ 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 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 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 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 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)

gwbas1c 10y ago

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.

matemaz 10y ago

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 https://www.tuleap.org Disclosure I work for the company that is the main contributor of Tuleap.org.