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
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 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 😅
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 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. 😅
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 😄
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 😄
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”.
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.
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 🤣