>The value for managers really should not be understated here.

Can you expand on that? I've never seen a manager use it well. They use it to generate numbers for their reports for the people they report to, and it doesn't tend to matter what those numbers or reports actually represent. For example, it's very easy for process to make velocity numbers complete hogwash.

Basically, as far as I can tell, it's great and being able to tell you what you want to hear, and not very good at providing usable insights that increases productivity, but people don't notice because they're hearing what they want to hear.

I actually like JIRA, but I'm also an admin in it and have taken ownership of the workflow (and really push back on any change requests to it).

One thing I definitely don't have is any managers living in it. It has all kinds of (useless, IMHO) reports it can spit out, but we don't spit them out, other one for time tracking some particularly-tagged issues (for the SR&ED tax credit program).

What is really awesome though is looking back through issues (and in general, JQL). For example, finding any re-opened bugs:

    type = bug and (status changed to reopened after 2017-01-01) and project in (PROD1, PROD2)

or building release notes (and excluding bugs that were found internally only):

    project = PROD1 and fixVersion = "2.0" and affectsVersion != "2.0"

We generally just look at these in the UI (though I suppose you could consider this a 'report' of sorts).

Well, once you're in that situation, you've already lost. Scrum is worthless if you haven't set he appropriate expectations with stakeholders at the outset. If you get them to understand definitions of Ready and Done as well as quality-first approach and being flexible on scope, then the backlog gives them all the information they need to understand what is being worked on and when. I've seen it done correctly a few times and I've even seen behemoth organizations get behind it and get a ton of value out of it.

For my money, the #1 benefit to scrum is improved visibility to stakeholders and any productivity gains to the dev are the result of them being able to work on things in the correct priority order due mainly to benefit #1.

> I've never seen a manager use it well.

This is very anecdotal. To see JIRA used well, you need both management which is willing to invest the time and effort necessary to learn the ins and outs of configuring JIRA, as well as competent and flexible stewardship by the admin team to enable desired configuration in a way which fits in with the rest of the instance and doesn't pollute it. If you pay attention to recent JIRA releases, Atlassian is trying to enable management to make the changes it wants to make without resulting in global pollution, but either way, you still need management to personally buy in.

I've seen everything from managers who refuse to customize workflows beyond "todo-in progress-done" to managers who use post-it notes on the wall for their "real" agile board, and then copy the changes by hand into JIRA issues to communicate status up the ladder. If your company's management isn't buying in, your company needs to either replace the managers or replace the tool, instead of trying to fit round pegs into square holes.

Now do a little thought experiment - what do you think they would be reporting if Jira or whatever else did not exist.

Agreed. The key is investing the time for a workflow with JIRA, confluence, Aha, etc to have a flow for making and completing requests and decisions.