I disagree. JIRA goes further out of its way to accomodate Agile/Scrum stuff than many other issue trackers. I was on a team once where we used FogBugz (without any of the metric tracking nonsense -- our managers didn't even log in to it, they just talked to us when they needed to know about progress) for a long time without any issue, and only after some big middle management restructuring did we switch to JIRA, specifically because managers wanted a tool that spit out useless junk about velocity and burndown. We even had to go and do really dumb training about "story points" and how to enter the progress data they wanted (which added so much overhead to entering things into the system that most of us just stopped, or at least cut every possible corner so as to not waste our time doing manual data entry for the sake of middle management).

Not every such tool focuses on these kind of pointless metrics so much. Using the GitHub issue tracker is joyful, especially when you don't have someone trying to micromanage you with it. Some tools focus instead on what the actual developers need to get their work done, instead of what managers want in order to be more micromanagerial.

Another tool that is starting to go down the dark path of JIRA is Asana, which is a shame because the original design of Asana was great. But now it's all about Scrum metric bullshit, catered to middle managers who have the power to choose it over other things, and usually don't make the choice based on developer preferences or rational arguments.

I'd say the title could be "Agile/Scrum metric trackers are a symptom of a management problem" and that JIRA is absolutely the poster child for such a tool, so it's not bad faith to tie it directly to JIRA. Though your point does bear repeating: JIRA is not the only tool that suffers from this problem.

It is "failure to use issue tracker effectively" and it happens all the time.

The problem is confounded by many little cuts. For instance, they think that the issue tracking system is only used by devs, so it goes on a dust-filled desktop machine from '03 that is stuffed in a corner somewhere, so it is underpowered and takes 25 seconds to load a page over my DSL connection and about 22 seconds at the office.

The people at the office don't care, however, because the boss thinks the issue tracking system is a waste of time. He bitches me out for taking 10 minutes to write up an estimate and then giving an estimate which is always "too long." I am carefully watching the star programmer to understand what he does right, and finally realize the reason he doesn't have this problem is that he doesn't estimate anything. Sometimes the testers put in tickets, and sometimes the star programmer puts one in, but the "product owner" never puts one in or bothers to show up at the scrum meetings down the hall.

Top management assigned a project manager to our team and she was putting in the scrum thing because my team had been going in circles for two years and they had to get a product in front of the customer. My boss pushed her out and she left to work for some kind of Christian charity.

At some point our boss got the religion of checklists, gave up on the idea of estimating or scheduling, and somehow we got it across the finish line.

But you can't say the same about every issue tracker. For example, GitHub Issues is so constrained that it's difficult for management to bend it, for good or ill.