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.
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.
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.)
There are at least 5,000 for JIRA alone: https://jira.atlassian.com/browse/JRA-161?jql=project%20%3D%...
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.
"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.
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.
I manage an Atlassian setup (Jira, Confluence, Stash, and Bamboo), and we don't seem to have any of the problems described in this article...
Well, except for the configuration part. There's options for almost everything.
The one gripe I have is that, while most things are configurable, there are some that seem like they would be easy to make configurable that get marked off as [wontfix].
Jira support is also pretty amazing. They're also really transparent and dogfood their application and expose their issue tracking to their customers. Bugs filed against Jira are done in Jira.
I 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 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.
Thanks for replying.
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 ;)
Which made me think it was an installation instead of the cloud based version.
I think Atlassian have too many pots on the fire and they can't keep up with it.
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.
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.
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
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.
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'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.
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.
This is actually why we created ZenHub 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)
We get lots of feature requests for GitLab and BitBucket support so those are two likely points to integrate with next.
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.
Ticket update overhead sucks.
It's borderline racist. Would you call a project management tool "Jewhub" or "Catholichub"?
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.
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!
In short, how do we make a Jira install into something powerful and useful?
That's full opposite of a Product.
Pros: best possible github integration, fast, lightweight.
Cons: none for us. There's nothing in Jira that I miss, at least.
Plus waffle.io has support for putting several repos on one board: https://help.waffle.io/hc/en-us/articles/225548707-How-do-I-...
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.
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.
Too late. The choice was made by those who'd barely use the tool.
Oh, and the VersionOne stories all link back to Jira which contains the original story for the functionality.
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/
Bitbucket-> Jira -> Bitbucket -> Youtrack
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'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.
Unfortunately it is easier to force a tool on people and call it agile than change an organization.
"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.
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.
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.
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'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.
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.
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.
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.
Sean (Disclaimer: I work on JIRA)
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. :-) )
Oh wow, that's fantastic - can I license that? :)
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'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.
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.
edit: looks like that's just a way to insert a single bit of content, not edit existing content :/
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.
Amen. I have to confess that I actually prefer Mercurial to git; it just feels simpler to use.
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.
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.
Git is quite elegant underneath the terrible UI.
There was a really good talk given by one of its lead developers about why it failed, called "Remedies for Frustration".
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).
 - https://docs.google.com/presentation/d/1awg1CHM1w128iOBp_JOx...
Also, the internal git model is elegant. Having used bzr for years, I never understood its internal model.