Of course. Can you describe [i.e. extract the technical baseline of] a product (information system, etc.) from it? From epics and (overlapping and/or contradictory) user stories? Hardly:
https://techcrunch.com/2018/12/09/jira-is-an-antipattern/
Quoting:
"I’m not saying JIRA has no place. It’s very good when you’re at the point where breaking things down into small pieces and finishing them sequentially does make sense. And, unsurprisingly given its history, it’s exceedingly good at issue tracking.
Let me reiterate: To write elegant software, you must keep both the macro and the micro vision in your mind simultaneously while working. JIRA is good at managing micro pieces. But you need something else for the macro. (And no, a clickable prototype isn’t enough; those are important, but they too require descriptive context.)
Allow me to propose something shocking and revolutionary: prose. Yes, that’s right; words in a row; thoughtfully written paragraphs. I’m not talking about huge requirements documents. I’m talking about maybe a 10-page overview describing the vision for the entire project in detail, and a six-page architectural document explaining the software infrastructure — where the city’s water, sewage, power, subways and airports are located, and how they work, to extend the metaphor. When Amazon can, famously, require six-page memos in order to call meetings, this really doesn’t seem like too much to ask.
Simply ceasing to treat JIRA as the primary map and model of project completion undercuts a great deal of its implicit antipatternness. Use it for tracking iterative development and bug fixes, by all means. It’s very good at that. But it is a tool deeply ill-suited to be the map of a project’s overall vision or infrastructure, and it is never the source of truth — the source of truth is always the running code. "
