Originally, we used JIRA for help desk ticketing, but the biggest use case for the solution now tends to be supporting Kanban and scrum-based agile development.
The weakness of the solution is that the interface is a little nonstandard, meaning it's very flexible. It's got a lot of power and gives the user the ability to combine different projects into the portfolio and move user stories between projects and link them. What I have found in a couple of organizations that I've used it with, is that the uptake tends to be a little slow because it's got a bit of a learning curve. It can dump data out to Excel and those programs, but it also has a big ecosystem of plugins and add-ons that you can get. I guess it has some strength in that regard, but if you're going to run it on-prem, you have to have people that are pretty well-versed in the program and have the time and capabilities to handle integration and make sure they're adding those modules correctly. Their interface is a little unique and I think that's partly because the core of the product has morphed into several sub-products, but the underlying architecture has stayed the same on all of them in that it was originally a help desk ticketing system. Now they are moving into these new use cases, including systems development, business projects, business processes, and redevelopment projects, but there is a problem with the nomenclature that they use, and some of the documentation is a little techy for moving it into those more business-focused use cases. It's a very tech-focused product and that's fair given its origins, but if they really want to expand their community of users, then they're going to have to move beyond that a little bit and polish it up.
