
Why I finally ditched Jira - virgil_disgr4ce
http://log.liminastudio.com/writing/commentary/why-i-finally-ditched-jira
======
strictnein
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
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
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
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.

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

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

~~~
GlennS
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?

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

~~~
GlennS
Glad to hear it.

Thanks for replying.

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

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

~~~
gotofritz
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

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

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

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

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

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

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

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

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

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

------
zbjornson
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
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-...](https://help.waffle.io/hc/en-us/articles/225548707-How-do-I-add-
multiple-repositories-to-a-single-board-)

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

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

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

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

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

------
Yhippa
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
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
+1 for "Individuals and interactions over processes and tools"

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

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

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

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

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

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

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

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

------
didsomeonesay
Agreed on all points. Self-hosted alternatives?

~~~
mattvot
We are having great success with Phabricator -
[https://www.phacility.com/](https://www.phacility.com/)

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

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

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

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

Speed: We’ve got some major projects that will be coming online soon that will
fundamentally accelerate the platform. This isn’t a small tweak, this is a
core architectural improvement that will make a big difference across the
board.

UI: Have you tried collapsible columns? This will let you minimize columns
that you don’t care about so the columns you do care about are bigger. This
allows you to see more of the ticket. Managing your backlog as the first
column in a Kanban board is ok when there are only a few issues. But, as your
backlog grows it’s hard to see many issues on the screen at one time. We’re
going to let you split the areas of concern into two different screens with
each one focused on the tasks at hand. The backlog is for backlog management
and replenishment; the Kanban board for the engineering team to select and
move the tasks through the workflow. This cuts down on noise and makes better
use of your screen real estate. We are looking at a redesign for the issue
view but more user research needs to be done.

Search: That’s good feedback…and something that we hear from customers who
have larger and larger issue counts. I’d like to break your comment into two
pieces, the speed piece, and the effective piece.

Regarding effective searches. We want to make sure everything in JIRA is
searchable and JQL is super flexible. But, we also make sure it is easy to
filter down to the specific information you need. In this instance, I’d advise
doing the search the way that you have, and then using the status filter to
separate out open issues.

In basic search, you can quickly toggle things on and off, for instance,
issues that are resolved. This should give you the sorting functionality that
you are looking for. Regarding speed. We are working hard on performance. You
will see big improvements here as we keep focusing on performance over the
next 6 months.

Organization: Epics are currently displayed as cards in Kanban and this works
well for certain use-cases. However, you are correct that it makes it harder
to identify what issues are associated with the epic and if used as a grouping
mechanism, displaying the card on the board isn’t as useful. That’s why we
will provide an option in the future to display Epics on the board, or use it
as a way to group stories the way we already do it for Scrum.

To answer your broader question, here are a few more ways that help you
organise your work in JIRA:

Kanplan: A great way to keep this work organized in JIRA Software is through
the plan mode (aka backlog) which can be found when using scrum or the Kanplan
feature in JSW Cloud. Trying to run a backlog and team task board together is
distracting. Managing your backlog as the first column in a Kanban works great
when there are only a few issues. But as your backlog grows it’s hard to see
many issues on the screen at one time, the cards are large and the ones you
care about are confined to ¼ of the page width or less, there’s so much
scrolling. Splitting backlogs and tasks to two different screens with Kanplan
helps- Backlog is for backlog management and replenishment and the Kanban
board is for the team to select and move the tasks through the workflow. You
can tab between Versions and Epics to see the progress of an Epic (e.g. number
of issues, completed, unestimated, estimated, and even linked pages). Also,
from this view you can mark the Epic as done and edit details.
([http://blogs.atlassian.com/2016/03/kanban-backlog-jira-
softw...](http://blogs.atlassian.com/2016/03/kanban-backlog-jira-software/))

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)

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

~~~
acdha
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
_the otherwise inevitable accretion of complexity._

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

~~~
acdha
Feel free!

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

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

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

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

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

