Andy Kelk


Why all the Jira hate? I’ll tell you why

I’ve recently retweeted a few tweets which weren’t exactly complimentary about Jira. For example:

Today a co-worker asked me why I was so down on Jira. Which is a fair question; especially since we use the entire Atlassian suite of products including Jira. So why does Jira set my teeth on edge?

The biggest reason is that there’s somehow become a conflation between using Jira and “doing Agile”; that is, many organisations seem to think that gaining agility is a matter of installing a tool. Of course, “Individuals and interactions over processes and tools” would have you think again; but maybe hoping that people have read the agile manifesto is a little optimistic .

Since Atlassian renamed the Greenhopper plugin to “Jira Agile”, the situation has only got worse. What you now see is still a “project” that is composed of “issues” but they’re magically displayed in swimlanes. So now we’re Agile, right? The thing is that Jira started life as a bug/issue management tool; and if your primary unit of work is an “issue”, you’re not starting from a great place . (As an aside, every time I hear a team talk about their user stories or features as “Jiras” a little piece of me dies inside).

You can see the impact this has had on organisations by looking at what skills they’re seeking in their job ads. Project Managers with MS Project skills have been replaced with “SCRUM Masters (sic)” with Jira skills.

The second way that Jira promotes bad practice is in its workflows. I’ll admit that it’s over five years since I had to administer a Jira workflow but it was hellish then and I suspect it’s not got much better since. Because there’s such complexity, there’s a big ramp up time and large learning curve; therefore, teams are not incentivised to change their process. Changing your process would be one of the key outcomes of an inspect and adapt cycle and a core fundamental of continuous improvement.

The final reason I’d advise people to steer clear of Jira? Because physical boards are awesome. A physical card wall is a totem for the team ; it’s an information radiator that anyone who’s passing by can look at and engage in a conversation around. Jira, meanwhile, hides that away behind a login screen – it actively discourages you from looking at work in progress.

Nothing creates a sense of connection with your work quite like a physical card wall . There’s a real sense of meaningful progress when you move cards around on a wall that you just don’t get by dragging them with a mouse. And there’s plenty of research to show that progress, no matter how small, is motivating for individuals and teams.

So why would you use Jira instead of a physical board? If you want a backup of the wall (what happens if someone defaces the cards or the building burns down) then take a photo every day. If you want interaction in a split-site team, have two card walls that are kept in sync by a team member on each end of the divide. If you want charts, draw them by hand – a big visible chart in the team area is much more valuable than a tiny one hidden on a dashboard.

I know some teams love Jira – I worked with one who were devastated that it had been taken away from them in favour of a (much larger, more bloated) agile lifecycle management tool. But I know just as many teams who’d much rather not use Jira or any electronic tool at all. All I’m asking is that you see the world beyond Jira – try not using any tool, try using a lighter weight tool and then go back to Jira if you really think you’re missing out on something.


26 thoughts on “Why all the Jira hate? I’ll tell you why

  1. In my current engagement I started with a bunch of teams that were waterfalling within sprints … and they had this big excuse of how their JIra process mandated them to work (with massively micromanaging stepped multi interim status subtasked based workflows … ahhhhhgggg). My immediate solution so that they would really understand the whole idea of Scrum and the teams’ behaviours and dynamics was: I got rid of Jira altogether. After a few sprints working out of the wall board. They then had the option to go back to a jira process reflective of their new way of working together, but they simply didn’t care about it anymore.


  2. I love Jira (much better than post-it notes stuck to my screen or trying to track change requirements spread across emails) but I certainly agree with the points you have made here, particularly about visibility, satisfaction, the feeling of progress, etc that Jira takes away.


  3. So many flaws in this post but I’ll try to stick to just a few. And while I do love JIRA, I love people more, so I never would use the tool as a crutch for poor behavior. Three main counterpoints to your post:

    – People thinking that just because they are using JIRA that means they are “agile” is not a problem with the tool. People are ultimately lazy and don’t want to do the hard work necessary to truly embrace agile methodologies — this is true. But don’t blame JIRA.
    – You haven’t used JIRA to develop workflows for five years, but complain that it still must be hard to use. Actually, Atlassian has done a bunch of work to help admins over the past few years and the tool is much easier to use now.
    – Yes, you don’t need a digital board and moving cards by hand is a wonderful feeling. But the fact is that so many teams are geographically dispersed that you need a single source of truth for your efforts that everyone can access. Colocation just isn’t as possible as most companies would like, and software helps connect those teams.

    JIRA is by no means a perfect tool, and you make some valid points about how it could be improved (especially how it calls everything an “issue”) but JIRA (or other tools) does many things right and the scorn just makes further conversations difficult.


    • Hi Dave,

      Thanks for commenting on my flawed post. Yes, it’s a rant, it’s not meant to be entirely balanced.

      You could substitute other tools in there for most of the points; Jira just happens to be thr most prevalent. However, I would argue that a lot of the marketing of Jira pushes it out of its original role as a bug tracker into being an ALM tool which it was never designed to be.

      I’m sure Atlassian has made it easier to use. I know that they’ve also invested huge amounts in making it faster. But it is still a very complex product with a steep learning curve. I know that from multiple conversations with people who use the tool regularly.

      For geographically dispersed teams, I agree that a tool is often needed but I would argue that you should pick the simplest tool that you can. And my personal opinion is that Jira doesn’t fall into that category.

      As I say in my final paragraph, I would always suggest that a team try not using a tool and then add a tool in to fill in any gaps they find. It’s much easier to add processes and tools to help in a particular area than to start with heavyweight tools or processes and then strip things out (loss aversion).

      I know lots of teams who are happy with Jira and that’s fine by me if they’ve chosen that. What I object to is a blanket mandate on using any tool or a mindless adoption of a tool without thought about what it’s meant to achieve.


      • You’re being too generous.

        Today I decided to give myself (as an Admin) rights to delete issues that were created in error. This took several minutes to google the solution and then find the secret hidden magic button. And even then, it required an Easter egg hunt across the screen to get it to reveal the actual button.

        Atlassian’s entire UX seems less like clunky design or incompetence than sadistic performance art. I mean, I’d just like basic dialog boxes (such as for adding labels to Confluence pages) to look the same independent of how I got to the dialog box. Is that asking too much?



  4. I agree that agile does not equal to applying jira. But seriously?

    “If you want a backup of the wall (what happens if someone defaces the cards or the building burns down) then take a photo every day. ”
    “If you want interaction in a split-site team, have two card walls that are kept in sync by a team member on each end of the divide.”
    “If you want charts, draw them by hand – a big visible chart in the team area is much more valuable than a tiny one hidden on a dashboard.”

    This really send us back to Stone Age.
    What you really need is just big TVs hung in your office rooms.


  5. Andy – you are not alone in your thoughts here – I have heard similar feedback from many the wonderful, diverse ecosystem of application development. However, you and readers of this post should consider the following in selecting any tools / designing processes to implement & execute agile in your development work:

    1) correct – installing a tracker (any) doesn’t make your processes or delivery magically agile; process design, training, etc need to be considered
    2) swim lanes (in boards), ‘issue’ types, and workflows in JIRA are all configurable; thus any issue with those points directly back to an admin’s config (but really the thought or lack thereof behind designing these); JIRA implementations fail because of bad configuration, and worse when laid on top of bad process design (compounding headaches for all)
    3) the cards / boards in JIRA contain the same schema / data as any other tool, and you can add custom fields, etc – I am not sold that JIRAs boards / cards are really different at all than others in other tools
    4) yes, JIRA is complex to configure, but that is learnable; end users simply need to learn the views, issue types, and workflows to be successful- they will never touch the configurations, which is where the real complexity lies
    5) there’s a lot missing here about what JIRA ​can do_ against other tools (what other tools don’t have): configurable security model, configurable notifications, custom fields, massive workflow customizations, a gigantic app store of sorts to extend out of the box, infinite programmatic extensibility capabilities, a slew of canned reports, ability to use query language (JQL) to access project data, cross project / program / portfolio management tools for professional services firms, time tracking, resource planning, and much, much more; you can call this bloat, or you can call this a powerful tool set (especially when you extend it with testing automation, repos, etc in tools like bamboo, bitbucket, etc) to manage everything you need from a PM or dev ops perspective

    Most importantly, there’s no ‘perfect solution’ out there for any tracking methodology and the tool set that supports it. The better teams out there acknowledge this, and they practice continuous improvement through ceremonies like retrospectives. What you have presented here is interesting, and it will likely draw many eyeballs and views on your site, but it is not a full picture of what teams need to consider implementing agile properly and how to select (and then configure) the right tool set to drive that forward.


  6. Great post and I’m feeling it one week into a project that is being driven by this tool. I also find it so busy and hats to find things, ask its labels, dropdowns, plugins ect. Totally gets in the way, I thinks it’s for the “doing agile” crew.


  7. The real problem with Jira to me (just going through onboarding to new project using Jira), is that it feels like it is developed by academics who try to over-develop an “agile tool” for business and process managers who don’t have a lot of experience with “real world” projects. Yes a tool does not make you “agile”.

    There is just too much to Jira, and basic features seem buried in the app. The “kanban” view does not expose basic story functions at the top level. Some basic task/story management requires so many clicks (for instance, changing the status of a story with subtasks), that is just seems overly complex. Also the rigidity of suggested workflows requires more customizations than seems necessary when compared to a tool like Pivotal.

    The whole philosophy of Jira seems tied to a “top down” academic understanding of management processes (trying to manage through graphs and analytics), rather than a “bottom up” style of real world “agile” project management. It’s really not that complicated, but Jira loves complexity it seems. (Also notification preferences can not be set with any granularity at the member account level.)

    Jira seems like an “excuse” for teams to justify unecessary complexity and workload at the management level. Just like academic bureaucrats like it. Apply the agile philosophy to Jira, and I don’t think it holds up, especially in the user interface.

    Would not be my first choice.


  8. Atlassian doesn’t pay tax, supports 457 visas which are destroying our graduates’ chances of getting a job and have an outsourcing branch in Manila. Used to love them, now hate them. Jira is OK though. Agile? People who love talking love Agile The rest of us hate it, and hate listening to them drone on, especially since they’re generally the Scrum Masters. (Caveat – I’m old, drunk, crabby and have worked in IT way too long. Luckily everyone politely ignores me.)


    • Well said Bill. Actually Agile is okay. The trouble is that people think things like SCRUM are Agile! They aren’t … especially SCRUM. It might be a good way to manage a project but it is contrary to the Agile manifesto! What is more it makes developers and engineers spend too much time pratting about with SCRUM processes and terminology rather than applying themselves mostly to the technical and design aspects of the problem or application domain.

      [In much the same way the exclusive focus on OO programming forces us to spend way too much time on the mechanics of OO (inheritance, polymorphism, overloading). I thought modern languages were supposed to reduce that sort of overhead. It was one of the criticisms of C that we had to manage memory and pointers. I suppose the real problem is that Java and C++ have implemented OO really badly. What was wrong with Smalltalk? It did OO properly long before C++ and Java messed it up. Better still, now that hardware is so fast that the overhead of creating Unix processes is no longer a problem, why not implement objects as independent Unix processes that communicate with messages. That would be as OO as you can get, without all the pointless complexity of Java and the like ? It would not help Windows programmers, but who is daft enough to use Windows for anything that has to be robust and reliable? ]

      What the IT industry needs is managers that can actually manage [rather than the typical engineer, promoted beyond their competence and labelled “manager”]. In 35 years as a software developer and problem solver I have worked with a manager that could manage … once. She was ex ICL, 74 years old at the time, and brought out of retirement for her skills!



  9. Many valid points made (in main post and the comment section) – thanks to all who’ve shared.

    Our company currently stuck somewhere in the early/mid adoption phase of Atlassian (Jira/Conf) and one (or more) of our traditional PMs are struggling with Jira as well (maybe some “hate” it as well) and they’d rather keep using our old 3rd party PM web tool made in 1990 because it’s easy/familiar and structured like a more traditional PM tool (hour/resource tracking, MS Project-like predecessors, etc).

    I’m on the dev side so am fine with Jira for most part though I certainly have bones to pick here and there w/Jira myself. But seems to me unless there’s a new/do-it-all tool out there I’ve missed the PM tool you pick either screws the Devs or screws the PMs – nothing w/the best of both worlds. Has anyone here found something w/the developer-friendly structure of Jira that traditional/MS Project-minded PMs find usable/friendly at the same time By the way on this note I’ve spent some time trying to get my head around Jira Portfolio in the hopes that it could be this magic (best-ish of both worlds) solution … but so far it seems like a weird hybrid of MS Project and Jira that neither our PMs or our Devs find intuitive out of the box.


  10. Dunno – i had to use jira, since our campany just wants to “use jira”.
    I ve used many other tools before, i rly tried to use … that … excel sheet … i faced the problems u will face with jira when u rly try to us it … no subprojects … (yes that could be a problem in greater teams) … no out of the box documentation (just spend more money and get confluence) … no out of the box agile assistance … (get another addon … get more addons … pay more …. ) and still …. not even standard.

    k great tool for waste money (thats it)


  11. What if Jira is not doing a good job of evolving their UI/UX because they use Jira to track issues and therefore nothing gets done.



  12. Thank goodness someone else noticed the problem with calling the fundamental unit of work an “issue.” Do people really think our work has gotten so bad that it’s somehow wrong before it has even begun?


  13. For me the worst design error is the way that it changes the order of the items when you are trying to alter the selection/filtering criteria. I thought this idea had been shown to be foolish when Microsoft tried it in Word (re-ordering based on frequency of use … who are the foolish children that make such stupid decisions … perhaps the same ones that invented a scroll bar that appears only when you point to where you hope it will be).

    Controls should not move around. Rapid use of a familiar interface uses “muscle memory” or (better) “kinaesthetic memory” which gets de-railed when interface items do not stay in the same place.


  14. I’d like to add that from the BSA perspective, JIRA is lousy. Everything takes 1-3 more clicks than it should. The layout of the story is terrible. Terminology is so non standard making the learning curve more difficult than it needs to be. Why component when the industry refers to it as teams?
    And why would it be so difficult to have the UI call a story a story and not an issue??? The same with sub-tasks ,why isn’t it a task? Blows my mind that a company of this size isn’t even using the standard, established agile terminology? Agghhh And ppl say this is configurable – hardly. Try to configure a division’s “issues” to display only for teams in that division, have more than one assignee to a story, or have the concept of a Feature between Epic and stories! And don’t get me started on migrating from another tool to get history into Jira – that should be simple, but it’s anything but, we were doing manual cut and pastes of stories for Comments, screenshots and attachments, That’s just awful! For all the talk that agile is a tool for for quality over quantity and continuous process improvement, Jira sure does a lousy job of demonstrating that


  15. Reading “Nothing creates a sense of connection with your work quite like a physical card wall ” 9 months into a pandemic is bizarre. Some of us will be working remotely for years to come, and before the pandemic, we had 3 members in NC, 4 in CA, and 1 in Hawaii. Even 5 years ago, the thought of maintaining project records on paper was laughable (no one ever actually records anything after the fact, we’re too pressed for time), and now it’s hysterical.

    What do you propose now that being in the same physical space is impossible?


Leave a Reply to Sofia Woloschin Cancel reply

Your email address will not be published. Required fields are marked *

*
*


Archives