How much time did you spend this week moving tickets in Jira (or other tracking tool) instead of actually coding?
I sometimes have this feeling th...
For further actions, you may consider blocking this person and/or reporting abuse
The boiling frog analogy is correct. Nobody decided one day to make Jira a second job. It happened one mandatory field at a time, and the people adding them genuinely believed each one was reasonable. Individually, they are, but it's the accumulation that kills you.
There's also something deeply ironic about developers, people who will spend three days automating a task that takes five minutes, manually updating ticket statuses so a burn-down chart looks clean for a meeting nobody fully believes in. The automation instinct stops at the Jira board for some reason.
That said, a lot of the bloat comes from different teams trying to solve different problems with the same tool. Dev wants simplicity. Management wants reporting. Compliance wants an audit trail. Nobody's wrong exactly. The board just ends up carrying everyone's requirements at once, and somehow it's always the developers who get blamed for not keeping it tidy
I think the last paragraph pinpoints the problem.
Multiple people with different perspectives using the same tool.
Using the same ticket, using the same board.
As far as my Jira knowledge goes the solution could be to create tasks with fields everyone needs. And subtasks with the fields only the specific group needs.
Then you can create boards for every group, where they only see the relevant information for them.
The next step is to trigger subtask status changes depending on ticket movements. For example a ticket movement from a developer changes the status or text of a compliance ticket.
As a developer just add the Jira ticket to the PR, PR merge or deploy. And based on that context the Jira ticket changes status.
Only the triggering on status I haven't seen working, but I know it exists.
The tool is almost never the problem, it is the use with too little thought that creates the mess.
I could hammer in a nail with handle of the hammer, but there is a better way.
Exactly, I totally agree 🙂
And honestly, I don’t even need all that automation. I’m perfectly happy to move a ticket to “Done”. It’s actually quite satisfying, like crossing something off a todo list 😄
The problem starts when I also have to fill in a thousand fields and tweak a bunch of things just so the reports look nicer. Because in reality, people will get lost in that anyway and won’t keep it perfectly updated, which ends up making the reports look even worse.
Or it turns into managers pinging developers every day to update tickets… and we’re back where we started 😅
You might not need all the automation, but there are a lot of small things that can be automated. Not only to be developer friendly, but to have the smoothest workflow for everyone.
Also when there is no pattern when some field needs to be filled in, that is most of the times a signal the field isn't needed.
I prefer as much automatisation as possible. Only going to jira to start a new ticket is dream come true.
That’s actually very true 🙂 A lot of those things could be automated.
We even suggested a super simple “automation” once. Just make the truly required fields… actually required. But of course, there’s never time for that. It’s apparently easier to just chase developers to fill things in 😂
Yeah most companies are not good at treating their internal tools with the respect they deserve.
And that is sad.
When companies are investing in AI all those random things in their workflows are going to bite them in the ass. Because an agent it going to fill in all the things. It is the best employee that has no boundaries.
I love the metaphor, but I’ll push back slightly: If development is the side quest, then Jira is the 'escort mission' that everyone hates but feels forced to play.
Your success with the 'Most Apps are Slower' article proves that people are starving for your brand of common sense. It’s ironic—the more 'process' we add to ensure quality, the more we drain the mental energy required to actually build quality. You’re doing the work of three people by absorbing that friction so your team can code. You might not have the 'Tech Lead' title on paper, but this post proves you’re the one actually leading the culture. Great read!
Thank you so much! 🙂 And yes, I think common sense is really the key here 😄
I totally get you! Between tickets, meetings, and all the theater we’re told is “essential,” it’s enough to drive anyone crazy… especially for simple folks like you and me ;)
Seriously though—how could anyone possibly survive with only three states in Jira? Without a sophisticated workflow and all that form-filling we both consider pointless, how is your app supposed to run? And more importantly—far more importantly—how else are all those Jira/Agile experts supposed to justify their salaries? :D
Hahaha exactly! 😄 The Jira experts need to earn their keep!
Obviously, nothing gets delivered without a perfectly structured process, beautiful epics and tasks, and all those carefully filled fields, otherwise how would we survive? 😉
And yet, somehow, at the end of the day I still get a million questions like:
“Sylwia, is this done?”
“Which version is it in?”
“When did we actually finish this?”
At this point I’m starting to think my memory works better than Jira’s 😅
“Sylwia, you are the company’s ultimate Jira — the Jira above Jira.”
Haha, Jira + the voice of reason in one 😄
I love this post, I feel totally same. I earned a tech lead title but that is not really important because I am alone team member for a year plus the team lead the BO/scrum master. I won that position because I am was the only person who is accept to maintane and improving a 7 years old applications chaos. But the Jira ticket playing on board even worst because we have a two boards. One for our partners company create ticket for us and one for our tem ( now we 3 developer again + uncounted agents ). Yes the coding part is not relevant for any one. Just the amount of done ticket number is the important. If we are counting on LOC then mordorjs is my right tool but the saddly truth is the solved ticket number.
The worst one is the devops team created automatic vulneralibity ticket generator. So on 2025 we are facing a 1500+ ticket. We are solved 1400+ under really fast, but that is a fake because that ticket just count on develop branch commit, but meanwhile that never deployed to production.
A final bonus is ticket micro management, where we need to write exact time we was spended on each ticket 30min precise.
Oh yesss, same here 😄 we also have to log time on tickets.
Honestly, I just don’t get it, it’s already beyond my level of comprehension 😅 One of my colleagues just starts a timer on a ticket… and sometimes forgets to stop it for like two days. So yeah, enforcing this consistently is… challenging.
What’s funny is that juniors are actually great at it. They log everything perfectly, because they need it for internal reporting and all those company processes 😄
Oh and yes, of course, a million tickets 😄
The best ones are those bugs where you close five at once with a single line of CSS. That’s when I truly feel like a top performer 😂
I see where you are coming from. Having to manage JIRA tickets more than "actual" work you have to do. It could be the case where the company is big to the point there is so many responsibilities, so therefore, JIRA tickets needs to be updated "constantly".
Finding that balance is hard because it varies by company and their goals. There isn't really much you can do about it other than adapt and finding ways where you can balance tickets and work.
It's hard to say since I don't have experience being part of a large company, so I can't say much but this is the best I could say based on what I heard from others and my personal experience. Thanks for sharing :D
In one company we actually fell deep into that Jira rabbit hole 😄 And then at some point someone wise came in and simplified it massively.
Honestly, even if the process was complex but at least stable, it would be manageable. But here… new fields just keep appearing all the time 😂
No, it's not just you. It's everywhere. Truth is, most of the time showing progress and reports is more important than doing actual work...I've been in countless times when solving the task can be done faster than creating a JIRA ticket and all the ceremonies behind it...
Haha YES!! 😄 I had a task like that too. We “analyzed” it for way longer than it actually took to implement in the end. I even pointed that out to management a couple of times… but you know how it goes 😅
I agree with "keeping Jira simple".
TODO, IN PROGRESS, DONE + maybe REVIEW, if you have analytic/tester role who checks tasks reported as completed before they are actually handled.
But I have also met devs who keep complaining about issue tracking, daily statuses and project management at large, to cover up their laziness and general incompetence. Without reasonable issue tracker and regular sync calls the project crumbles into chaos.
Haha, seriously? 😄
In my experience it’s often the opposite — the biggest slackers are also the most creative when it comes to looking busy in Jira and on calls 😂
I have to push back on one thing right away: “a software developer is lazy by nature.”
I feel personally attacked. I’m a hardworking engineer… sometimes. 😅 Do you know how much effort it takes to aggressively copy-paste prompts? That’s real work.🤣
Jokes aside, on the Jira topic, you’re definitely not alone. We often joke that we’re not really a product company, but a Jira- (and Excel-) driven organization. It’s honestly impressive how many properties and workflows people can come up with when given the chance.
About a year ago, we had a series of three 30-minute meetings for 150+ people, where a “Jira expert” introduced new states for bug tickets. We originally had five, now we have nine. Nine! Apparently, that still wasn’t enough before. 😄
All hail corporate life and our beautiful dashboards. 📋️
Haha, okay, I’ll admit, 9 states for bugs is already… impressive 😄
But honestly? That still sounds like amateur level.
In my case, when I want to close a bug and set it to “Resolved”, I also have to fill in the “Resolution” field… and there are 28 options to choose from. Twenty. Eight. 🤯
And the best part? The last one is something like “Xd11526”.
No description, no context. I’m honestly afraid to pick it in case it deploys something to production or summons a manager 😅
I had something similar in one of earlier projects.
Resolutionfield with about 10 options, but some of them had also required textarea to put more info 😂Oh yes, of course! 😄
And the best part is, no matter what you put there, if it’s anything other than “Fixed”, nobody really understands it anyway, and people will still come back asking: “so… why wasn’t this fixed?” 😂
28? 😅 Okay… I take it back. I’ll start being nicer to our Jira experts, it seems we’re still playing in the minor leagues.
That last option though… “Xd11526”? That’s not a resolution, that’s a gamble. I’d totally click it on a Friday afternoon without a rollback plan… just to see what happens. What could possibly go wrong? 😄
Exactly 😄 Tomorrow’s a holiday in Poland, so today is basically Friday energy. Very tempting to pick “Xd11526” right at the end of the day and just… close the laptop. 😅
Some time ago I discovered Task Management feature in WebStorm. It does few things:
This is beautiful 😄 The plugin just needs one more thing: a special agent that automatically fills in the remaining 100 required fields 😅
I don’t think development itself is a side quest, but in some orgs it definitely gets treated that way. Process starts dominating over actual problem solving.
Exactly, and the scary part is, it happens so quietly 😄
You just reminded me how much I hated it in the previous company I worked for. It was a big corporation, and I have a feeling that the bigger the company is, the more people are drawn away from what they were hired to do and end up doing side-quests like Jira management or sitting on calls.
Now I work for a small company, and we have just 3 columns in Jira and almost no calls 😄 I totally recommend!
Oh yes, that’s a beautiful state 😄 Hope it stays that way!
From my experience though… over time Jira somehow always gets more complicated, and the number of calls magically starts to grow 😅
I do ... which is why I launched AbleTime (literally last weekend ... so spanking fresh it barely shows up in Google yet). Was always frustrated that tracking time didn't automatically move the project forward, so I built a thing that does that. Track time against tasks, the KanBan and Gantt automatically reflect the changes, end of. No more "thumbs through 3 hours of meeting notes/slides things around" guesswork. Happy to give you a tour ;)
That sounds awesome, congrats on the launch!
I’d definitely be curious to check it out, but unfortunately in my case it’s corporate life. The tools are pretty much decided for us upfront 😅
pushing back a bit - teams use Jira to compensate for missing async context. good docs and clear ownership would kill half those status tickets. the tool’s not the problem.
That’s a fair point 🙂 And just to clarify, I’m not saying the tool itself is the problem. I actually appreciate Jira a lot and wouldn’t want to work without some kind of tracking system.
I’m also not fully convinced that better docs or clearer ownership would solve this particular issue. From what I’ve seen, a lot of this complexity comes from the need to produce nice-looking reports and burn-down charts for management layers. And that’s how we end up with more fields, more states, and more “just one more thing”.
fair - docs don't fix decision latency. some of those tickets exist because the call just hasn't been made, not because context is missing.
Haha don’t worry, we have plenty of calls already 😄
lol that tracks - somehow more calls never solves the latency part
I've been through the same search. Jira worked fine until our team (5 devs) started drowning in ceremony, sprint planning, grooming, retrospectives eating into actual dev time.
What ended up working for us was dropping sprints entirely and moving to a continuous flow approach. Instead of two-week cycles, we just have one prioritized list. Top item gets worked on, shipped when done, next item starts. No planning meetings, no velocity tracking.
The tool we built around this is FlowBoard (flowboard.dev), it's specifically designed for small dev teams that want to ship without the ceremony. Auto-generates changelogs when you release, has a public roadmap you can share with stakeholders, and visual QA so nothing ships untested.
Full disclosure: I'm the founder, so take this with a grain of salt. But happy to answer questions about the continuous flow approach regardless of what tool you end up using.
That honestly sounds wonderful 😄
The only question is… how do you get that into some managers’ heads? 😅
We’ve at least managed to cut down the number of calls quite a bit recently. That used to be a whole separate level of chaos.
Once you start going down this path, you started getting into dedicated JIRA managers (with different titles) in organization whose main job is to ensure everyone fills every details and create reports for management/executives.
“Jira manager” sounds absolutely terrifying 😄 Glad we don’t have one… yet 😅
If a tool isn't making the work faster, it's just friction.🤔🤷
100% right!!! Or maybe it's making it faster - for managers 😅
🤣🤣 just maybe
Wow, promoted by the legendary Sylwia, no wonder why I got some spikes in my views after a few days off from my laptop haha.
Haha, imagine: just write some random nonsense and suddenly you’re a legend 😄
I guess this one comes with how high you are ranked in the company that's why it feels like another job. Some people love it, some people don't.
Kind of yes, kind of no 🙂 Everyone is supposed to fill in all that Jira stuff. At least that’s what we’re told. How it looks in reality… well, we all know 😄
Are there any credible alternatives to Jira?
I remember complaining about Jira to a coworker back in 2010. I asked him if he knew of any software alternatives to Jira that are better than Jira.
He said "Yes. Jira 1.0. It was wonderful, before they bloated it with stuff." (He didn't say "stuff", I substituted that for a bad word.) He was so dead set against using Jira, he left the corporate world and founded his own software development company so he could avoid using Jira.
He is much braver than I.
There are alternatives. I’ve used ClickUp before, and even plain Notion in some cases 🙂
But honestly, I think your coworker had a point. It’s not really Jira itself that’s the problem, it’s how we use it. You can keep it simple.
So switching tools doesn’t magically fix anything. If a team (consciously or not) tends to overcomplicate the process, they’ll manage to do it in any tool 😄
Spent 6 months solo on a productivity app and the meta-irony hit me hard reading this. The first month I tracked everything in Jira-clone tooling. By month 3 I had built so much "process" around solo work that I was spending 30% of my time updating my own status to my own ghost team. Quit it cold turkey, switched to "just commit and ship", and shipping velocity doubled.
The harder truth in your article: even when the overhead is genuinely useful (cross-team alignment, audit trail), the granularity is almost always wrong. Subtasks of subtasks of stories nobody reads. A friction tax masquerading as transparency.
What helped me on TAMSIV was capturing micro-tasks via voice in 3 seconds instead of opening a board, picking a sprint, choosing a label. The bottleneck was never knowing what to do, it was the activation energy of the tool. Voice + flat folder hierarchy = the same coordination outcome with 1/10th the overhead.
Curious whether your team experiments with stripping ceremony rather than adding tools. Most "Jira fatigue" posts I see propose new tools. Yours just names the disease, which is rarer and more useful.
Yeah, that really resonates. In our case we unfortunately don’t have much control over the tooling — that choice is made way above the team level.
To be fair, the number of calls has been reduced quite a bit recently, so it feels like there’s at least some growing awareness that all this “extra” work is getting out of hand. But exactly as you said — if even a solo dev can get trapped in maintaining process instead of building things, then in a large team (especially in a government-scale organization) it’s so much easier to spiral into that overhead.
Spot on. It’s reached a point where coding feels like the reward I get for finishing my Jira admin work. The irony is that the more we optimize for 'visibility' and 'reporting,' the less there is to actually report on because we're too busy moving tickets
Exactly, and apparently the concept of context switching is still unknown to some people 😄
Just the other day, I forgot to move the bug to QA testing status. Got a bit of virtual stares in the scrum call (=_=)
Haha, perfect timing 😄 My manager doesn’t even get annoyed anymore — just calmly follows up 😂
This story highlights the common frustration of software development getting bogged down by administrative overhead, like constant Jira ticket management. It suggests that when the process becomes more important than the product, coding can start to feel like a side quest to the main job of navigating project management tools.
Exactly — that’s a great summary 🙂
Side quest is the perfect metaphor and the most depressing one because side quests are optional. JIRA tickets don't feel optional.
I ve had days where I closed 6 tickets and felt nothing And days where I solved one weird bug and felt like I'd actually accomplished something The ticket count doesn't track meaning. It tracks motion.
What you're getting at the is this the main quest? question is the one that keeps me up Not because the work is hard. Because I genuinely don't know what the main quest is anymore Ship features? Close tickets? Make the graph go up? None of those feel like winning.
Maybe that's the real shift. Not from coding to prompting. But from knowing what done looks like to just doing the next ticket.
Thanks for this. It's going to sit with me. 🙌
Honestly, I’d probably enjoy moving those tickets — it’s like crossing things off a todo list, very satisfying 😄
But the moment I start thinking about all the fields I need to fill, statuses to pick, things to update… I immediately lose the motivation 😅
The observation that the best developers you know engage with Jira the least—not out of laziness, but because their attention is somewhere more useful—rings true in a way that's almost uncomfortable. It makes me wonder if the friction isn't really about Jira itself, but about who the tool is ultimately serving.
When a ticket system has three states, it's serving the team. Everyone knows what's waiting, what's moving, what's done. But each new field and status transition tends to serve someone one step further from the work—a PM who needs a chart, a stakeholder who wants a dashboard, a process person optimizing for visibility over velocity. None of that is malicious, but the cumulative weight lands on the people least likely to push back, because pushing back on process stuff somehow gets coded as "not being a team player."
What I find interesting is your point about government systems—where the stakes are genuinely high and tracking matters—actually reinforcing the case for simplicity rather than undermining it. If consequences are real, the last thing you want is a developer's mental energy being drained by tooling overhead when they should be thinking about edge cases and failure modes. Complexity in the tracker doesn't add safety; it just adds distractions in the place you can least afford them.
I'm curious: in your experience, have you ever seen a team successfully push back on Jira creep without it becoming a political headache? Or does it always require someone with enough seniority to absorb the friction on behalf of everyone else?
Yes — actually, I’ve seen it happen once 🙂
We had a pretty complex ticketing system as well, lots of fields, statuses, all the usual. And at some point someone just said: this is too much, we need to simplify it.
And the interesting part? The conclusion was basically: if management needs extra data for reports and dashboards, they can take care of enriching it themselves — instead of pushing all of that onto developers.
So it is doable. But yeah… someone has to say it out loud. And realistically, it usually isn’t a regular developer who can make that call 😄
You need a BA or a Scrum master to do the JIRA handling. Please stay as a developer and don't get into the board movements 🤣
Haha, I swear the more BAs and Scrum Masters you add, the more fields magically appear in Jira 😄
Get your API token and start automating Jira :-).
Haha, give the agent a week and it would submit its resignation 😄
Every few years we discuss the same thing.
And nothing really changes 😄
🤍🧊Thank you for your participation and for sharing this benefit. We wish you continued success and lasting good fortune.🌊🐬
PracHub may be useful
yes