Since many people are also complaining about Jira UI, I've been working on a CLI app during the holidays in a hope to speed up my Jira workflow to some extent: https://bit.ly/38P12bv
Why Jira Sucks
471–480 of 530 posts
Re: Why Jira Sucks
#472Earlier quoted context omitted.
My primary advantage over the Scrum Master that I replaced was hand writing all the required JIRA changes during the meeting, and doing them on my own time later. I was a hero! Highly recommended.
That would be great. On a client project a few years ago I effectively bullied the product owner into doing that. We were a few weeks away from a launch. I had sat down with our designer and we made a list together of about 30 changes we needed to make (“this is the wrong blue. This is 2px too big. Etc). The product owner wanted me to put all the changes through our normal process - make a jira issue for each one and…
Great story, but re the “killed respect for Agile” bit:
Agile done right is all about less process. It’s right there on the Agile Manifesto:
> Individuals and interactions over processes and tools
I’d also read https://agilemanifesto.org/principles.html for an illustration of what is considered valuable — especially the bit about simplicity which process heavy (aka fake-agile) agile consultants totally miss; also the bits about what constitutes project progress & how to most efficiently convey information.
You should be able to tailor your agile processes to what makes sense for you. Following the herd and insisting on agile ceremonies “because everyone else does it / someone told us to”, even to your team’s detriment, is cargo-culting.
In your case you clearly tailored your process to something that improved your efficiency and met your reporting requirements, so, as far as I’m concerned, you’re doing agile “right”.
Re: Why Jira Sucks
#473Earlier quoted context omitted.
Do you prefer to... not have all the details in front of you for a task you're about to work on?
Generally as a senior dev part of your job description is to figure the details out. Not have them provided for you. As a jr or early mid level you can expect to have the majority of the details ironed out and nicely laid out for you to work on, but someone at some point had to actually figure it out and put it in the ticket. Whether that is you or someone else likely depends on your level, the stage of the company,…
Of course there are details to figure out. Why wouldn't I want all the information from design and other teams in front of me when I'm figuring those details out? I'm struggling to see why a detailed ticket is a bad thing.
Re: Why Jira Sucks
#474Earlier quoted context omitted.
You want devs to not care about anything but fixing technical problems though. At the end of the day: technical problems can have hard constraints that dictate the usefulness of your product and the people who have the skills to investigate and fix them should be dedicated to using those skills to fix such problems. Worrying about users, funders and other teams is what Product/Project and Engineering managers are mea…
The issue was that the dev didn’t consider why an imperfect estimate would be useful. So they didn’t understand problem solving at a basic level. Engineers not prioritizing what they work on is not a good idea. Especially when the particular ticket was something like adding a feature to an iPhone app.
in my company we actually do estimate work and many people are so bad at it. however we learned from that and our trainees need to track how much time they spend on issues and then we talk about that after two weeks, so they get an understanding why something takes x or y and they can learn to estimate work.
estimates do not need to be perfect, but we encourage everybody to estimate more time that they think instead of less. so for the estimate they need to think about the problem and do not code like monkeys without any kind of plan on how to fix the specific problem/task.
Re: Why Jira Sucks
#475Co-founder of Zepel.io [0] here. Thank you for giving Zepel a shoutout in the Jira alternatives section of the landing page. Would love to get feedback from the community regarding our App. [0]: https://zepel.io/
Did someone at Zepel.io create this Why Jira Sucks site?
No @iblaine, no one from Zepel created this website. Noticed that we were getting some traffic from this source and found this page.
Re: Why Jira Sucks
#476Earlier quoted context omitted.
I've been the core dev on an 18 person team, I wrote 80% of the jira tickets and did about 35% of the code. 6 month of coding project to first launch. I used jira to remember. I wrote tickets for missing features, kludge's and bugs to be fixed, etc. I yelled at the managers to prioritize and estimate faster so I would know how on track we were or if we needed major strategy pivots. Yes I'm an assembly line robot and…
Totally. I actually don't know how people that work in big enough organizations can possibly not like Jira (or a tool like it). I would go crazy with the amount of things I would have to remember, their status, how to prioritize, how something was previously done and when, etc.
You'd probably end up recreating a rudimentary version of it in a spreadsheet
Re: Why Jira Sucks
#477Earlier quoted context omitted.
> They don't. Funny. Can I get $100 please? Every team has their own process that is tailored to their needs, process is decided by devs, not managers, managers only do "I'd like to have this kind of visibility" requests some times and I yet to see those requests introducing any kind of burden, usually very miniscule things. We have very simple process in our team with two issue types for devs - task and bug. We have…
Sure. Post the video(s) and a Venmo account. > Sprint planning is about 30 minutes... That's like saying Santa Klaus is real. I want to believe you. I really do.
Sprint planning takes 30 minutes for our team too. And exactly like OP, backlog grooming is done during 1-1s with leads.
I am sorry if you find it that much hard to believe.
Re: Why Jira Sucks
#478Earlier quoted context omitted.
So... "shouting across the room" for a ticket which is so trivial it doesn't need to be documented is OK, but telling someone to "fuck off" for doing it is not? Your priorities are backwards. I would not work at a place where interrupting me during coding to fix a trivial bug is considered acceptable.
Each to their own, I wouldn’t want to work at a place where we were just working on our own stuff and if you need something from someone you have to raise a jira ticket before you talk to them even though you are in the same room. The best teams I have worked with tend to be more collaborative.
> The best teams I have worked with tend to be more collaborative.
which means more writing to be done. not everbody knows what was SAID an hour ago.
Re: Why Jira Sucks
#479Earlier quoted context omitted.
You express a number of notions here that are part of the fantasy of managerialism [1]. An especially big one is that if we render all important decisions unto a managerial class, they will make optimal choices. If that were true, startups would never succeed, because established companies would use their greater resources and market power to gobble up market niches before startups could get momentum. In practice, ev…
That's not what I mean at all. JIRA doesn't imply any sort of top down approach. In fact, I'd argue it's the best tool for those tight feedback loops. Each ticket is a versioned history of the decisions, feedback and work history of a single task. Startups can get away without tools because they can communicate very tightly. That doesn't scale much past an org of even 20 people. Not everyone can talk directly to the…
You specifically said Jira wasn't for developers, but rather for the managers and stakeholders. That sounds pretty top-down to me.
I also don't understand how you believe Jira can be best for tight feedback loops, but also agree that the tight communication and focused teams make Jira unnecessary. That seems contradictory.
Re: Why Jira Sucks
#480What about the burn down charts? Every project I’ve ever worked on, features are finished, apps and websites are shipped, clients are happy and pay the bills, yet the burn down just goes straight to the right and never down. Sometimes right and up if people added more tickets during the sprint. We look at it at the end of the sprint and say ah well and continue on our way. Then sometimes a PM type decides it’s a prob…
Hit the nail on the head with this. It's sort of like a gimmie "problem" that can be weaponized if anyone is in the mood, but mostly just ignored entirely.