Jira is a customizable ticketing platform. I manage a different ticketing platform at my company (ServiceNow), and I see a lot of crossover in system complaints.
- People ask for a tightly controlled workflow and then get mad when they can’t freely move between states. There will always be exception cases so don’t lock down your states in Jira unless it’s for some audit reason.
- Too many custom mandatory fields to enforce some sort of process compliance. If you have a process you want people to follow, do your job and educate and have recurring trainings on the damn process. The system can’t do the educating for you, and if everything is locked down and mandatory all the time it means the ticket can’t even be worked on in phases, or the requester responded to quickly, without having to spend five minutes on data entry - for every ticket.
- People try to use a particular ticket type for something it’s not meant to be used for and get mad when it doesn’t work. This seems to be less of a concern on Jira than ServiceNow but use the correct ticket types for what you’re doing and you won’t have a problem.
- People hate the underlying processes put in place, and blame the system. This is what the article is addressing.
I do have to agree with this article as a whole. There are a lot of managers who see what Jira can do and expect employees to do it all without considering whether it will be worthwhile. Especially if you’re not running agile and sprints, Jira isn’t the tool for everyone. Most companies have a Microsoft 365 license and Planner works well for team task tracking in general (and it’s integrated with Teams).
At the same time, some employees just hate the idea of ticketing at all and rage against the idea of being held accountable for their tasks, and sucks to be them I guess.
We used JIRA effectively at my last job, the things that made it work for us:
- stop adding shitloads of required fields. Title, description, branch, priority (defaulted), status (defaulted), type (bug/feature). We might have had some others, but that was all I remember being required.
- stop writing shitty descriptions: spend more time writing something that your co-worker can use. Respect their time enough to try to include enough detail for them to actually use the ticket. Be available to answer questions when they are assigned a ticket you wrote.
- you don’t need extremely granular statuses: the functional role of the assignee is enough to determine what “state” it’s in, trying to codify a unidirectional flow of tickets is maddening and overly complicated. Work is messy, it flows back and forth, you do not need a “rejected by qa” status. Just leave it open and reassign to the developer with a comment. Managers find out when individuals are submitting half-assed work on a regular basis, you don’t need JIRA for that (unless you need metrics to fire them… different problem).
I agree with the premise of the article, JIRA is a communication tool, not a management tool.
Nope, I absolutely hate Jira and everything that I needed to do in it at my old job. Luckily for most stuff we had other issue trackers (multiple, but that’s another issue), but whenever I had to touch Jira or any other Atlassian tool, it was a bad time.
This blog post is just strawmanning for a tool that rightfully deserves to be criticized.
Nah I hate jira because it’s so damn slow to do any action
I’m okay with tickets, it’s the price we pay, but there is a serious lack of “in and out” with jira. As a dev, I want to spend as little time as possible in a software like jira.
