Jira Reviews

We are using the product for general task management, largely. From a software development community perspective, obviously, we use the task management piece - the foundation to what leads into the development and the CI/CD pipelines and et cetera. Outside of that, it varies widely. At its very core, it's task management, however, then it's used by various functional areas within the company. For example, we have contracting and procurement that utilize it. And we have marketing that uses it and security, IT security, audit, compliance. Various functional areas across the company use Jira. We use it a lot. More and more business teams are using it today than were previously.

We also use it for reporting. With task management comes the Jira out-of-the-box reporting. We had Advanced Roadmaps before it was included in the product. And now that it's just rolled into the Data Center product, you obviously don't have to pay for it specifically anymore, however, that's the most scaled reporting that we have. Then, as far as any other apps are concerned, we really just use time and status for measuring continuous flow and have more of a Kanban approach. Of course, some workflow, add-ons, and things of that nature to add some value such as training for Jira.

I'm less concerned about marketplace apps due to the fact that, whether you go to Azure DevOps or Microsoft, or whether you go to Atlassian, there are countless apps out there that will extend the application itself. 

It's an organized, collaborative, transparent way of working and that's really helped the organization overall. Otherwise, many teams would still be managing work in Excel spreadsheets and/or SharePoint, which is just ridiculous. At least this provides some sort of structured approach that can easily be queried and have data extracted. I use Jira for everything at work. I don't even use email that much. It's through @mentions and all these different things. 

The solution is great for helping teams to collaborate.

There are tons of apps and add-ons for the solution that help you expand its offering via third parties.

The product allows you to become very structured in your approach to work.

You no longer need to email people. You can mention them right in Jira and have conversations there. 

It's easy to extract data and do queries.

The way that Azure DevOps rolled out their boards and made them flexible is something that Jira lacks. You want a workflow and you're configuring your columns and you're mapping status to columns, however, in Jira, you can't have more columns than you do status. Whereas in Azure DevOps from a Jira admin perspective, it's amazing as it doesn't care what you need in terms of what your life cycle is. The underlying process template is very generic. It's just like a to-do, in progress, done ordering basically, except they use the words inprog or active, resolved, and a couple of others. Open, active, resolved, and maybe one more.

No matter what they do to the face of the board, they can create 15 columns if that's what they want to represent their lifecycle, which gives them that visibility and the ability to then report on that. The reports will run off of that, however, they never have to actually reach out to an admin and say, "I need you to build me a workflow." On the admin side of Azure DevOps, they could modify the underlying process template to include things like that would be the equivalent. They refer to them as rules in Azure DevOps, however, it would be the equivalent of post functions and validators and these things within Jira.

The great majority of teams don't care about that. What they care about is just being able to properly represent their lifecycle. It provides a great deal of flexibility and it cuts down a tremendous amount on admin having to build a workflow for each and every team that feels that their process is somehow different than everybody else's. It lets them basically self-organize. Agility, being able to just boom, build out their workflow as they see fit. That's the biggest thing that I've seen so far that Jira could really learn from.

In Jira, say on the team, no matter the methodology, it doesn't matter what I'm practicing, if I am using the tool for a while and I've compiled some sort of history. If I want to change my workflow, say my team is today using to-do in progress done, and tomorrow, I decide I want to use to-do in review and done, and I apply that new workflow, I have just now effectively lost all of my histories in terms of reporting. Now the issues themselves, of course, the activity, the history, all of it is still there, but you lose all your boards. Not the boards per se, but the reporting within them. That includes all of my past sprint burndowns, all my past velocity reports, some of that stuff gets completely wiped away. The only way to restore it is to replace the original workflow. It's insane. It's the way that the application is built and it's all tied in with it. I had it explained to me one time by Atlassian, however, it's just really a bad thing - especially when you're in a large enterprise organization and then you get somebody like me that comes around that they hire to come in and be the product manager. The first thing I say is, "We need some fricking governance. You can't have 100 plus statuses. What the hell is this? Or 500 custom fields that half the people aren't even using."

The statuses in the workflow standardization become virtually impossible as I can say, "Hey. This workflow that you're using is a terrible workflow. Let me fix it for you. Let me give you a better workflow. Let's talk about this. Let's build a really good workflow." We need to go through that pain and then I have to tell them that, "Oh, and by the way though, if you adopt this new workflow that I'm sitting here telling you it's going to be so much better, be advised that you're going to lose all your reporting history." How do you think that's going to go? Probably not so good. That is a huge downfall. 

I'm an avid user of Jira and I've been using the product for at least a decade. At my company, I'm the product manager, however, I'm also the Jira admin support desk, and I wear all the hats for 4,000 plus users. Therefore, I'm very familiar with Jira. 

I'm learning Azure DevOps as well, mostly due to the fact that I'm being forced to. The company is adopting Azure DevOps. I'm fighting to keep Jira around. It still has the value that it adds to the company. The business side of our company is largely embedded in the tool. 

The stability is excellent. I've never had any issues. If anything, it's probably one of our more stable products.

I have found it difficult to scale. With the Advanced Roadmaps, we do have the ability to add additional layers of hierarchy. However, that's been a struggle at our organization as we're trying to adopt a Scaled Agile Framework. Unfortunately, with the Advanced Roadmaps for Jira, the hierarchy is very inflexible, which I've actually opened up a ticket with Atlassian on. 

With the Scaled Agile Framework, you need to be able to move from the program - what was once called referred to as the program layer - and you may have a large solution layer, or you may not. If you don't, you go directly to the portfolio layer. That said, in Advanced Roadmaps, it's very inflexible. You can't skip a level if you want to. You have to go through this regimented hierarchy, which does not bode well for a Scaled Agile Framework environment. I've never been able to crack the code on how to get around that.

Also, the reporting in Jira seems to be very team-oriented. Yes, you can create boards and things using queries and combine items, however, I find it difficult to scale without an additional app or plugin. For example, if you've got a program and you've got a bunch of teams that are supporting said program, I find it difficult to be able to scale and show a program increment, a PI. That level of reporting is lacking. I know that there are apps out there for that. However, unless you're willing to spend a small fortune on a lot of apps, well, the core product doesn't scale above that of the team level.

The solution is extensively used in the company, and we are quite sizeable. We have about just under 4,000 active users. It used to be used it was 5,000 and then COVID hit and we lost a lot of contractors that were cut when COVID hit. It's that mostly and then some of the users are being siphoned out of the Atlassian tool stack now into Azure DevOps.

99% of the technical support staff have been awesome. We actually have premier support. They seem to be very responsive and very helpful. Where I personally get frustrated is if there are issues and we give feedback and advice, and they respond with a "thank you, however, we aren't changing". They will tell us it's not a priority for them right now, and it can be frustrating. 

There's a lot of different things out there that people feel that should be included as basic functionality within the application. Maybe some of those I agree with, some of them maybe not. However, when I see something that I consider a bug and then they tell me that, "Yeah, that's not a priority right now." I find that very frustrating. Just now, I was trying to configure the application for the ability to create or comment on issues by setting up a mail server. And there's a known bug. I don't know if they consider it a bug. However, when you configure that and somebody actually does reply to a system-generated email notification, it will add it as a comment, which is great, yet it will also automatically attach your profile picture to that issue.

Therefore, as many times as you comment or reply via an email is exactly how many times an attachment will be added to your issue, which obviously is ridiculous. That cannot be purposely designed that way. Who wants attachments of your own face added to an issue? And it just takes up space needlessly. Their response to me was, "Well, that's just not a priority right now." Basically, not enough people have complained about it yet and they must not be using that functionality, therefore they're not worried about it.

I wasn't at the company when they originally set this solution up. There are certainly some things that I would do differently in hindsight, however, I wasn't here when they set it up originally and can't speak to what the process was like.

Pricing information you can just get right off the internet. Atlassian is notorious for not negotiating. They have never negotiated up until very recently. They've started to negotiate contracts as they're really trying to push the cloud. They're trying to get people to move to the cloud. In some cases, they are willing to negotiate costs if you're willing to move to the cloud. Not only costs. Terms. They treat everybody equally, which honestly, I respect.

However, large enterprise organizations like the one I work for, hate it. They hate that as they feel like they have some sort of clout or they need to be able to throw their weight around a little bit and they needed to be treated specially. One of the biggest things that hurt Atlassian is its unwillingness to work directly with large enterprise organizations. It works well with smaller companies, however, their approach to large enterprise organizations really hurts them. The Microsofts of the world will send you a whole crew of people that will come in and do demos and meet with your senior executives. Atlassian has that in the equivalent of a TAM, technical account manager. 99% of the time if you call Atlassian, they'll say, "Whoa. You work with one of our third-party vendors." Which, okay, there's a ton of third-party vendors that are fantastic I'm sure, however, people want to see Atlassian. When you get into a larger enterprise organization, they don't appreciate the fact that an Atlassian representative can't come in and take the time to meet with people and do these things when they're spending that kind of money. It doesn't bode well. They really don't like it.

That's largely why they're being pushed out of Jira and onto other solutions. Microsoft, for example, has invested time and energy. Microsoft has also negotiated terms and pricing. Large companies would rather have a relationship with a company like that than a company that doesn't negotiate or come to see you.

I've started to look at Azure DevOps. I am personally the Jira product manager, and what I'm trying to do is have some sort of comparison. It all became very sudden. I was recently asked if, by the end of the week, I could provide a recommendation as to when one team should use Azure DevOps versus when one team should use Jira. I was told to look into why we should use one over the other or if they are so similar that it doesn't matter and we could just get rid of Jira. I've done very little research so far,

Obviously, Microsoft and Atlassian are competitors. Back when Azure DevOps was TFS, it wasn't even a close comparison in terms of boards. Jira blew TFS out of the water. It wasn't even remotely close. Well, then they obviously knew that they needed to improve and they basically made freaking boards look like Jira's boards and made some improvements on top of it in some ways. I suspect that there may be some underlying limitations with DevOps. I know that in Jira you could allow teams to just create the workflows that they want within reason, of course, while pulling from a series of predefined statuses and these things. Whereas, I don't know that you can do that in Azure DevOps. But then again, I don't know that it's necessary since you can already create the boards the way you want to.

I know that some people so far from customer feedback, tend to like the dashboards more in Azure DevOps. They seem to like the reporting options. They find it easier and more intuitive to use, however, I don't really know anything more about it than that. I just need to really know the pros and cons of each of these things. Here's what's surprising to me, if I'm at Atlassian or if I'm Azure DevOps or Microsoft, you would think that they would have something like that. You would think they'd be going, "Who is my biggest competitor? Well, I need to know these things so that I can improve my product and compete with him." However, when I reach out to them, I don't have any real comparison to work off of.

I did find one article online that was written by Atlassian and Azure DevOps versus Jira, however, it wasn't well-written.

We're just customers and end-users.

I upgraded the application back in December, so we're on 8.13 right now. While we're currently on-premises, one of the things that were on my to-do this year was to consider moving to the cloud, which is something that we are very interested in doing.

Currently, we're using the Jira Data Center.

Our company has barely scratched the surface of the power of Jira in my personal opinion as they've just largely tried to do a bunch of customization. There was no governance set when I first joined the organization. People were just allowed to create whatever they wanted in any way they wanted, and it needed to be cleaned up, which doesn't help my efforts of course. 

There might, in the near future, be many people who get siphoned off of Jira as the company already made a decision that Bamboo and Bitbucket are going. They're moving all the software development activities into Azure DevOps. We already know that. That's already been decided. Atlassian doesn't know that, however, it's happening. The process is probably going to take a year, maybe two. We haven't really rolled it out yet or defined or planned it out. That said, it will happen. Whether or not Jira sticks around though, we don't know yet. I'm hoping it will as I love using it.

I'd advise new companies that one of the biggest things to do at the outset is to just put some governance in place before you go rolling out. It's a super-powerful application. However, if you are in a large enterprise organization, you need to establish an advisory board before you go rolling this thing out. Really think about a steering committee. How are you going to handle requests for customization? What will the board handle? What will the board not handle? Or the committee, whatever you want to refer to it as. They obviously did not do that here when they rolled this out. It can be a really great thing if you have that in place. It's not overly cumbersome.

I'd rate the solution at an eight out of ten.

I work with a credit rating company in the US. As a scrum master and project manager, I have to make sure that all the impediments are removed for the team. I work with product owners to make sure that all initiatives requested by our stakeholders, who are mainly compliance and regulations people, are moving in a timely manner.

I use Jira to make sure that we are capturing all the work that is requested, and it is progressing in a timely manner. I am in charge of a squad called Core Operations Reporting. A squad is usually focused on one or two initiatives. The goal of our squad is to automate regulatory reports as much as possible. I talk to our stakeholders to ensure that any errors in credit ratings are dealt with in a timely manner. A lot of these requests are ad hoc, and we prioritize them in sprints in Jira. 

It was very easy to learn Jira. I can't explain how easy it was. The hardest part of my job is understanding the business and communicating with difficult stakeholders and difficult people on the squad who are resistant to change and agile methodology. The fact that Jira was so simple to understand was a huge boon in my book because I didn't have to waste time trying to learn the tool to get work done and move the squad along. It was very easy to understand.

As a scrum master, I run daily stand-ups, and they are run directly from Jira. During these stand-ups, to make sure that there are no impediments, I run through all of the open issues and action items that the team members have. The feature that I really love in Jira is called Issue Navigator. It allows me to customize how I want to show the user stories within Jira to my squad. 

I can use Jira Query Language (JQL) to write queries to see the stories that are there for the current sprint. I can also sort them by assignment. I am able to call each assignee and have them walk through the status of what they did yesterday, what do they plan to do for the next 24 hours, and if there are any blockers or impediments.

I also use Jira is for burndown charts. A burndown chart provides a visual depiction of how quickly the squad is closing out user stories. It gives us an indication of how efficiently the squad is performing. I also use the Active Sprints function and a feature called Planning Poker. Planning Poker is an add-on, and it allows me to work with my squad members to estimate the complexity of user stories. It allows me to estimate user stories in an unbiased way with my squad members. It is important that people are not piggybacking on other people's estimates, so when a business requests a functionality, I use Planning Poker to have people send me their estimates in an unbiased way. They cannot see what other people have estimated. This way, they have their own unbiased view on specific user-requested functionality and its worth. After that, we end up talking out like, "Why did you think it was a three? Why did the other person think it was a five?" So, it allows an unbiased way of estimating user stories.

One major issue that I, and even our business stakeholders, have noticed is related to Epic Link. In Issue Navigator view, Jira allows you to enter JQL, which is basically like SQL. You just enter a query, and it displays the stories that satisfy the query. There is a field called Epic Link, which is basically a high-level designation for a bunch of user stories with a common goal. Epic Link is typically of different colors. When Epic Link's background color is a dark color, it effectively becomes unreadable. I am looking at my screen right now, and there is an Epic Link called Click View User Request. The background is purple, and the text is black. It is almost impossible to read it unless you click on it or give it an extra minute of viewing. That's basically what needs improvement. I wish there was a way for us to change the text color of Epic Link in the Issue Navigator view.

I've been required to report on metrics, and I don't know if it is possible with Jira, but there needs to be an easier way to capture a few metrics. For a two-week sprint, we are required to report on a number of metrics such as committed, completed, added, and rolled over. There is a way to see the stories that have been added after the sprint has begun, but there is no easy way to aggregate this, which is a waste of time. I wish there was an easy way for Jira to explain to me what has been added after the sprint has been done. Currently, it is a bit difficult for me to tell.

In addition, when rolling over stories from one sprint to another, it is kind of difficult for me to find out how many story points were actually rolled over without going into Jira and doing an analysis. I wish Jira would somehow aggregate that information for me so I can easily report about it. There should be an automatic aggregation of how many story points were added after the sprint began and how many story points were rolled over to the subsequent sprint.

I also wish Jira had an indicator to tell you that you are approaching the limit for the story points that can be delivered during a sprint. Typically, there is an established capacity for each sprint. I take an average of all of the delivered story points from the past six sprints, and I use that number to estimate how many story points can the squad deliver. I wish there was an indicator in Jira that tells you that you are approaching the number of story points that can be delivered during the sprint. I don't think there is an indicator like that, but such an indicator will be very helpful because then I will be easily able to see that we are approaching the limit. I can then talk to the squad members and say, "Okay, we need to remove some story points from the sprint because we're reaching capacity."

My experience with Jira is pretty extensive. I pretty much use Jira every single day and multiple times a day. When I'm not using Jira, I'm using Confluence. I also use SharePoint.

It is 100% stable. Stability is also dependent on a lot of factors. Jira has been down once or twice, and people go crazy. In almost two and a half years that I've worked here, Jira was down only a handful of times, and I don't think that was Atlassian's fault. Atlassian is the company that is responsible for these tools. 

I am not really aware of things in terms of expansion. However, there are some add-ons or extensions for expanding the functionality of Jira. The Planning Poker tool seems to be an add-on. Similarly, there is also another extension or plugin called Structure that was previously going to be leveraged. We haven't moved forward with that because we're using more of a manual solution in the metrics reporting. There is another add-on called Dataplane Reports. So, scalability is definitely there, and there are definitely opportunities to scale horizontally and expand the functionally of Jira through plugins and add-ons. 

In our organization, we only have 5,000 employees, and probably 70% of the company is using Jira. which includes the business as well. The business is also learning how to use it, and they understand that it is a very powerful tool. I would say about 3,500 out of 5,000 people are using Jira.

I didn't have to contact Atlassian. We have an internal Jira support team that answers all our questions. I don't think they have contacted Jira support in a while.

Its initial setup was not done by me.

Its initial setup was done by Jira administrators.

I am not sure about the pricing, but I know its licensing is on a yearly basis.

The main advice would be to just use it as much as possible and try to learn the basics of JQL, which is Jira's proprietary language that allows you to tell Jira exactly what you want to see. It is pretty self-explanatory and not hard to use. There are so many different fields in Jira such as issue type, key, sprint, summary, Epic Link, reporter, assigning, status, story points, and components. You can add the required columns to the Issue Navigator view, and it will spit back exactly what you wanted to see.

You should also learn what kind of value it can add to the organization before just jumping in. Try to talk to senior management and figure it out. You should learn how to read the burndown charts to basically understand how efficiently the team is working. Every organization has an IT organization, and I am sure the majority of them are using Jira.

I would rate Jira an eight out of ten. No tool is perfect, and there is obviously room for improvement.

We have different software projects. I primarily use Jira to define and plan projects for agile-based project management. We use different aspects. We have scrum-based management for some projects and different systems for others.

The agile framework works well, and I pretty much live by that. Everything, such as sprint management, is laid out.

It is easy to use and implement. It provides me with pretty much everything that I need to be able to do day-to-day planning, task management, and work log efficacy.

It is a great centralized tool for everything. You can use it for your local team management to communicate with your developers. You can also use it for your management team and for communicating with subcontractors to keep track of work products, work logs, and perform at the minute status.

For how I identify tasks and break down use cases, I wish there was the ability to drill down Stories multiple levels deep. You have Epics, Stories, Tasks and Sub-tasks. Each of which can go one level deep. It would be nice to be able to be able to define Stories multiple levels deep in order to break down super complex use-cases. That is my only pet peeve. Other than that, they've been improving year to year, and each new version seems to have increased levels of improvement.

I use another product that synchronizes well with Jira called Worklog Assistant, by Sohail Somani, which runs separately to Jira. It is a great product that allows you easily keep track of work performed and generate all respective Jira worklogs at the press of a button. I've been using it for years, and it just makes it very easy for me to keep track of what I am doing with an accurate time tracking mechanism. I think this would be a nice tool to integrated with Atlassian Jira.

I've been using it since 2008.

It is pretty stable. They've improved things over the years. Back in 2008, when we were starting to use it, different issues used to come up from time to time. It was still relatively stable. Now, I rarely run into a problem for which I can say that it is a problem with the tool, as opposed to user error.

It is pretty scalable. I was actually kind of surprised at how much data I can put in. It doesn't slow the tool down. It is quite scalable, and it worked well for the projects that we've done.

We're a small company. I can't compare myself to IBM or Raytheon. I can talk for a small company with up to 45 employees with X number of projects. Because of COVID, we've had to pare down, and currently, we have two users who are using it. I myself use it on a regular basis. Four or five years ago, we had subcontractors who used it with us. At that time, we had seven or eight users, including clients and subcontractors.

It is being extensively used at the moment. The only increase in usage would be to include other individuals on it.

We used their support early on, and they were helpful. At that time, we were using the enterprise product, which was a purchased product. So, as a paying customer, you got straight-up support. They were good. There were some bugs and issues early on that were difficult to get through, but they worked them out. Now, we have fewer people, so we use the one to 10 person option, and I haven't had any reason to call support. I haven't had a need to use their support in years.

They self-use their product for defect management. You can always go to their website and find what's going on. They have forums, et cetera.

In the previous company that I've worked for, I've used Bugzilla for defect management. Task management was in-house, but I don't remember the tool that we used to do task management. For building up sprints, etc, we used a Wiki-based system. It probably was TWiki at the time. We had set up our own Wiki-based environments for doing management, et cetera. We also had Excel spreadsheets. I didn't know about Jira back then in the previous company.

We did some research when I started with this company, and we chose to use Atlassian. It wasn't just, "Oh, the company was using it." It was one of the things that I was part of instituting. We did what we call Decision Analysis and Resolution (DAR) to determine what was the best bang for the buck and what covered our needs, and then it evolved from there. After I started using Jira in this company, a lot of things were easy to do.

Its setup is semi intuitive. There are certain things for which you need to look at the instructions. It also depends on how complex your environment settings are.

Initially, back in 2008, it was a little bit more difficult, but they've improved the installation process. If you have a very basic setup, you can just pretty much install it right out of the box with maybe one or two changes. There're certain things for which you need to have some IT knowledge of your environment in order to be able to set it up. Other than that, they have really automated it pretty well. Jira is one of their keystone products.

Its initial deployment took hours or maybe days because there were things that I needed to understand, but they've improved it a great deal. You can pretty much be up and running within an hour, but it also depends on your environment.

Its implementation was an in-house job.

In terms of maintenance, I take care of its maintenance. Its maintenance is minimum, and only one person is required. You can easily run backups. We use Microsoft SQL Server for backend data management, and we automate the backups. We do daily backups, etc. If anything goes wrong with the tool we have, we can just rebuild it from scratch, and we will be fine because our data is there.

They also have built-in backup utilities that you can use. There is an XML-based one, which I do like to use from time to time just as an alternate. So, you do have different options.

We've seen a return on investment when it comes to Jira.

For very small companies, if you have less than 10 individuals, it is $10 a year for each of the products. When we were a part of the enterprise and had more than 10 people using it, or before they came up with this solution for small companies, it was $2,500 a year for the license for Jira and Confluence, and I believe something like $600 a year to perpetuate the license. I can't remember if it was $600 or $2,500 annually. It was for up to 25 people at the time, and this was in the early 2000s and mid 2000s.

There are a number of add-on products that you can sync with Atlassian Jira. Confluence, FishEye, Crucible, and Bamboo are different Atlassian products, but then there are sub-products. They have what's called Atlassian marketplace, and you can buy products for certain needs. Tempo is a perfect product for doing time management and timesheets. It was also $10. So, you have a bunch of different types of add-on products that different individuals have built that work well with the tool, and they are quite stable.

One piece of advice, which they also give in their documentation, is to use your own database management system. They give you something that you can use. It is called HSQL or something like that, but you can use what your company can afford, such as MySQL or SQL Server, and manage that yourself. It will help you to do better data management and backup management. I would use the built-in backup management system as a backup, although I haven't had any problems at all in years. Just for a warm fuzzy, it is always good to have a backup system.

I would recommend looking into primary tools depending on your needs. If you're doing software, FishEye and Crucible are great products to utilize with it. You also have Confluence and Bamboo for continuous build management. Tempo, of course, is good for certain types of management.

I would rate Jira a nine out of 10.

It's pretty much for engineering development, Scaled Agile purposes for engineering development, for managing basically the epics and the stories and the capabilities and everything that we have to deliver in sprints. We're not using it as a ticketing tool or anything like that, for operations. We're using it purely for managing the development stuff in a Scaled Agile manner.

The solution is easy to use. It's pretty dynamic. It allows us to basically handle everything that we need in terms of a backlog, and we're trying to do it in an organized manner, so we know who works on what and how to size the story points so we can ensure that our epics burn down from sprint to sprint.

In terms of the general way that the tool functions, it seems like it's a pretty good fit-for-purpose for what we're trying to do. We've never thought about replacing it with another technology. 

The initial setup is pretty straightforward. 

The stability is pretty good.

There are a few things about it that I think need to be improved in terms of the ability to build reports. We would like to be able to use the data from Jira to help drive Gantt chart roadmap-type views of not only what we're building, but rather where we're going.

What we've elected to do in a couple of cases is just pull the data out of Jira and then pull it into Power BI so that we can try to get some of the more sophisticated information that we want out of it. We actually experimented with building portfolio views so we can see stuff in real-time. In some ways, it's okay. In some ways, it's just a little lethargic for our purposes.

We'd like to be able to manage things in real-time and by looking at stuff. We're doing PI planning, Program Increment planning, and that kind of stuff, and it's not always a good facilitator for that. We tend to pull it out and put it into other tools to manage that, and then we get it back into Jira as that's our system of record for where all the stories are kept. That's probably the biggest headache with it.

For some of the portfolio stuff that we did, the queries were so complicated that it was just taking forever. It was like watching paint dry for the results to come back. We would be in a meeting and then we'd hit a refresh and you're waiting for what seems like an eternity.

The solution could use API integration to take feeds from other tools so that we can read them better. We got one camp using an ITBM tool from ServiceNow. We have Jira running in this other area, and having an API between the two so we could actually collaborate between the two tools. However, API integrations with other tools would be helpful so we could either take data out of it or put data in it, thereby making it more of a data-driven platform that integrates nicer with other platforms. That, I think, would be something I would like to see.

I've been using the solution for four years or so. 

I haven't heard people really complain that it's unstable. We haven't had very many performance issues with it. I don't know if it was a network problem or what it might have been, however, I haven't really heard people talk about performance problems other than when we were trying to use it for portfolio views and that got kind of weird as queries were just complicated. Beyond that, the stability has been fine.

The issues that we have with scalability aren't necessarily with the tool as much as it's how we're using it. We're a big company so there are a lot of people using Jira, however, we don't really see how the projects correlate across different activities within the company. When we're trying to get two integrated roadmaps and trying to get to a point where we're collaborating, doing inter-sourcing of a solution, and we're all in Jira, there are times where we're in it and yet we can't collaborate and work together, and so we start replicating things across the two projects.

I don't know how much of that is the issue with using it how we are versus the product itself though. 

We have 8,000 to 10,000 people using the solution currently. That's across many departments. We are a company of around 150,000 people. There may be people using it that I am not even aware of. I only have visibility of what I'm doing and what I'm exposed to in terms of integration with offerings and that kind of stuff. I know when we were managing licenses, we used to have a DevCloud team. For their scope, it was in the 8,000 to 10,000 user range. 

The solution is being pretty extensively used. Likely usage will grow as the company grows and takes on new business. I don't know if it's going to organically grow exponentially as it's already being used where it needs to be used and currently we're only using it for development activities across the different offerings and platforms. It's not used as a day-to-day run-and-maintain ticketing system to manage customers or issues or anything like that. I'm sure there'll be some incremental growth as we take on new business and grow as an organization.

We use Jira. We use Confluence as an extension of that, and then we also use ServiceNow, the ITBM capabilities of ServiceNow as well.

We had a DevOps team that ran our cloud environment, and they basically spun up a project for us, and it was pretty straightforward. It's not like we were installing it in the cloud. People just said, "Here you go, and you can just start using it." After that, we just created a project for what we were doing, and then we were on our way. I wasn't really involved with any part that was problematic or anything.

In terms of maintenance, pretty much everybody is maintaining their own instance. We've got somebody that manages what's in the cloud for the company, however, it's pretty much hands-off in terms of day-to-day support issues. We had a few people that were supporting it when there were problems, however, it's just a handful from what I understand.

We're just customers and end-users.

We are likely using the latest version of the solution. I don't know what the latest version of Jira is, however, I'm pretty confident we are.

The advice I would give is it's not a solution for a novice person that doesn't know Scaled Agile. Users will get out of it what they put into it, and if you don't know what you're doing you could set yourself up for a nightmare when you're using the tool. My advice is that the better you structure yourself and understand Scaled Agile and how you want to set up the project the more successful you'll be at using it for your organization's purposes. If you're going in there as a novice that doesn't understand anything about Scaled Agile you could create a mess for yourself and then it won't give you the value you are seeking.

I'd rate the solution at a seven out of ten.

I'm overseeing the developments done in Jira. 

The thing that I do like about Jira is that it is relatively easy to understand. In some respects, you don't have to read a lot of ticket information, and you can start pulling down. Everybody is using it, and it works for a lot of people who are just doing enterprise development, cloud-based development, and things like that. It is built for the general audience. 

It is a good defect tracking tool. It has a lot of capabilities and functionalities. There are a lot of graphs and a lot of tracking. It can be sprint-driven if you want. There is a lot of data that you can pull out for estimations. It has got a lot of out-of-the-box functionalities that are kind of like the Jazz platform for out-of-the-box scrum and other such things. 

It also works well with all the integrated tools that you buy.

One thing that I don't like about Jira is that when you do an export, it only allows a thousand issues. So the export feature needs to be better. 

Another thing that I don't like about it is related to epics. There are times when you simultaneously want to have a story tied to two epics, one driving the content change and one driving the format of that evolution. It is not truly a parent-child relationship. It is a single-parent relationship to the stories. It would be nice if you had the capability to tie in multiple epics to a particular story. It is a rare case, but we have that. 

Setting up and executing a triage board should be simpler in the sense of how you do the admin. I come from a regulated space, and there should be easier control of who approves and reviews a system board to oversee all the defects. It should have easier out-of-the-box solutions to allow us to set up a triage board at the system level, the software board level that reports to the system board, or the test level that reports to the software board at the system level. There should be out-of-the-box solutions to migrate that and say that who are the three people on the triage board and if they have these admin privileges. Software review board and test review board would be another thing.

We have also had a problem with the integration with Bitbucket Pull Request data. It is an add-on to the tool, but it is not fully integrated. It is not easy from my perspective. Jira, Bitbucket, and Xray should be smoothly integrated. Xray is pretty good, but Bitbucket is standalone. So, when you pull out the data from a comma-separated value and want to move it into a new database, you have to reenter the data. You somehow lose that Pull Request capability. Pull Request through Bitbucket and the review of the code should be easier to manage. You could use a software package called Crucible to go ahead and mark how you did the review, who reviewed it, and who is the independent reviewer or subject matter expert, but that also should be easier to set up. If they want Jira to be the one-stop shop of the view of all of your deliverables, not just from a defect tracking perspective, but also from a requirement perspective, a code perspective, and a testing perspective, it needs to pull out more data and work better as an integration tool. 

I'm using Jira for the requirement repository. When I do requirements, it would be nice if I had the capability to say that for your requirement, I'm going to give you traceability to support a traceability report from Xray. I'm also going to give a requirement ID number in the ticket. You could use Jama and things like that, but it would be nice if Jira supported that.

We had on-prem and cloud deployments. We had to go to on-prem because of the security measures that were deployed. On-cloud didn't have the same capability. If you have one database on the cloud and the other one is on-prem, they don't talk to each other. It would be nice if you pulled it in and you could switch and say that I want to go on-prem because I got greater security risk.

When we go into the regulated space, I require a lot more integration and capability for tools. It is very hard to get tools to perform at that level because they're built for the general audience. In the regulated space, whether you're in medical devices, avionics, or any other regulated environment, tools have to be validated. I've worked with some companies in the past that had the capability to facilitate that validation. With one of the solutions, you could go ahead and buy a validated suite or a requirement package that will validate the tool for your use, but it is such a small market for Jira around the world that nobody really cares about that.

On their website, they show a bunch of tools that work with Jira, but it would be nice if they gave you examples and said that if you're a regulated medical device or regulated, here's a solution that could work for you. Here is Jira. Here is Crucible, and here is Xray, and here is what it'll do for you. They could also ask how do you do the requirement management? Do you use Jama that ties to Jira? It would be awesome if they had some use cases that showed people how to use Jira as the building block and how to add something on the front end for requirement management, and something on the backend for testing, such as Crucible for the peer reviews and Xray for the test management. People would see it and say that I want to do that.

It would also be nice if it could provide some lock-out capabilities based on your development and environment preferences. For example, you can specify that no one can close a defect until it has been tested, or until a particular task is complete, you can't go to the next phase. It would be cool if you could have something like this set up versus someone configuring it in the background.

They have got 10,000 licenses of Jira, and they have teams around the world deploying it across multiple geographies. All of that works fine.

I haven't used them because this company has its own tech support. So, I've been reaching out to them.

Most people who turn to Jira say that the return on investment is much better. 

Jira and its solution off the shelf are cheap. It is cheap for startups.

It depends on what you want to use Jira for, and what's the problem you're trying to solve. If you're going to do defect tracking and management of an artifact and you have got requirements, code, and tests, and they all got to summarize, you have to then go ahead and take Jira. You can then buy Crucible for the peer reviews and Xray for the test management and get them to work seamlessly with each other. 

I would rate Jira an eight out of ten. It is fairly cheap. For a nine or ten, it would be like DOORS and Jazz platform, but the problem with that is that it would become really expensive.

We're using JIRA in combination with Xray as a test management tool.

The Xray module gives us test management capabilities, right. Where we can store tests and test executions and so on. That's basically where we moved our test out and we left Quality Center behind. 

With Jira, basically, you have a story. You try to estimate the story and then you have to try to have coverage for each story with test cases. We sometimes use it for our automation perspective. We're using the JIRA Xray API to write bad test results into the tool, through an API call rather than going through the UI. Our continuous testing pipeline in GitLab will automatically update the test results through the Xray API. That's it.

The thing that was helpful, in my opinion, was the reporting. I was able to do real-time reports myself without having to wait for data import. 

The product has lots of dashboards that could be created also in Confluence using Jira features. I really like that. I am able to make it transparent to everyone where we're standing in regards to, for example, test automation or test coverage. We could easily integrate Confluence with Jira, produce some handmade dashboards, or use the dashboarding inside Jira itself with the various reporting options there. 

It's totally sufficient to cover our use cases right now. I have no gap at the moment.

There is always a bit of a performance problem. It's a bit slow to load the whole data. When I load those dashboards onto Confluence, it always takes quite a bit of time to get all the data in Confluence. It's a lot of queries.

The only thing that was bothering me was the performance issues where it was very slow. 

We started using the solution three years ago. I've used the solution since 2016 personally. 

Stability has improved over time. It was crashing quite a bit and the minute it crashes, the organization kind of stands still. It's a huge dependence we have on it. However, it was 99% available in the end. Only some kind of maintenance announcements might affect it. Other than that, it was quite stable.

Likely every single user has Jira as we are fully delivering software with that. It's between three and 5,000 users. It's company-wide and there could be thousands of users. All the development work is documented there. It's used for our agile teams. You have teams that are using agile scrum.

It's very flexible and it supports both ways of working. It's very helpful also with child transformation. The whole organization moves into agile and everybody is relying on those dashboards and daily standups and it has heavy adoption. Everybody's using it.

The solution is easy to scale and that's a bit of a problem. It's highly customizable and you can also destroy Jira by over-customizing things. If you, for example, want to raise a bug and you have 50 mandatory fields, you kind of lose patience with it.

That's not really a Jira problem. That's the customization from inside the bank where there are lots of different requirements being put into the tool and it can destroy the user experience in the end if they over-design it. If it takes you ten minutes to raise a bug due to the mandatory fields. That's really annoying and that's a big problem.

Internally, I've used technical support. I have not had contact with Jira externally.

We have a separate team in the company who is dealing with all the support tickets.

There are three levels of support tickets and they probably have connections directly to Jira people or Xray people.

We're looking into transitioning into possible options in GitLab only. GitLab test management would be a topic. However, there we are not clear about the features yet.

We came from Quality Center, the fat client version, and we moved to JIRA Xray three years ago. Now we're making a decision as to whether we want to move away from JIRA Xray to something else. That's the open question right now.

I wasn't involved in the initial setup of the whole thing. I was just a consumer. We were just migrating our data over from QC into Jira Xray and that migration process was okay. 

We lost some data, however, in general, the assets were transferred over and we could continue there and leave the whole old world behind and start working on the new world. 

From a migration perspective, it was almost seamless. Afterward, you just had to learn a little bit. That said, it's quite straightforward. The JQL query language was something new at the beginning yet easy to pick up without big pieces of training. You can train yourself pretty well with the documentation that's available on the internet. I was able to teach myself almost everything without having to go into any training. 

I can't speak to the maintenance requirements involved. That's handled by another team entirely.

I don't have any details in relation to costs or licensing arrangements. 

We have an on-prem installation of Jira. I cannot tell you the version of it. I don't actually care, as long as I can store my stories. They're moving into a soft solution, potentially next year, with it.

I am very happy with the tool. I would recommend others to use Jira anytime, as it's super flexible and there's a lot of things that are not being leveraged at all. There's so much power in the product - we don't even know half of it, I would say, in the organization. 

I'd advise new users to not over-customize it. If you just get it out of the box, you already have a really good evolution and you tend to break it by over-customizing it.

I'd rate the solution at a nine out of ten.

For the past two years I have been administrating Jira for our enterprise organization, in which there are about 300 end users. Apart from an administrator, I'm also a hands-on Jira user now.

Our main uses for Jira include asset management, project management, Scrum project tracking, Kanban projects tracking, and cost tracking, as well as productivity measurement.

I feel the strongest feature of Jira is its workflow engine. It empowers us to automate our workflows within our organization. It's the one characteristic of Jira which I think can help any organization, be it in any domain. Also, its Scrum tracking capabilities are a great help, and these come out-of-the-box with Jira.

In the way it is deployed, I think Jira is too dependent on the third-party applications that are available in its marketplace. If we could get some of the basic functionalities which are offered by these third-party applications, that would be ideal because each time we need a new functionality, we have to purchase a new plugin as an add-on.

Then, on top of that, we have to keep paying the maintenance charge for those third-party applications along with Jira's maintenance cost. The functionalities of some of these plugins are pretty basic, which a user would expect out-of-the-box, instead of having to pay repeatedly for it.

Also, on the security front, if Jira could have a default, inbuilt encryption mechanism for all the data it stores, it would help organizations which handle sensitive data like healthcare or financial sectors.

I've been using Jira since 2020.

It's pretty stable and I haven't had major issues with it.

The current deployment is not that scalable. But when we go for an alternative deployment model such as the data center model, it's scalable.

We were on the server model for Jira, which is being discontinued in 2024. The data center model is pretty scalable. I think that shouldn't have any issues, but it is limited. I think the data center is limited to only two instances of Jira running in parallel. That should be sufficient, and I think with data center being the only on-premises deployment model, I think it's all right to have that.

Overall, I'd rate the support an eight out of ten. I don't see any glaring shortcomings but I do see certain things which could be addressed better in their support rather than just providing documentation and saying, "Please follow this documentation."

If they could provide on-call support for some of the issues and give us a path to follow, that would be sufficient. They don't need to sit down and resolve the issue for us. But if they could point us in the right direction, I would be satisfied with that.

That said, we do get that kind of support, sometimes. There is personalized support and we have a dedicated Jira expert who helps us with our tickets. But if we are stuck, and we are not able to find a solution for our problem, then we should have a second level of support, which could be an on-call support. That would help us better.

Positive

It was straightforward to set up Jira, even though it was on-prem. But to set up the supporting modules for Jira, like the web component (e.g. Apache) or the database component, requires a little bit more effort. The Jira application does provide support on that front, but the support is pretty limited, because they do not vouch for the other modules that aren't built in to Jira.

Apache is a web server that interacts with Jira and I think they should better support the deployment of Jira with web servers at any enterprise or cloud-level. That should be provided as part of the deployment journey itself. As it is currently, their support that helps us integrate Jira with Apache comes off a little short.

We have our own compliance team who applies security patches and those patches are available from Jira directly. The maintenance is pretty easy and we pay a maintenance fee for Jira software. If there is any issue with downtime or service is completely stopped and we are not able to handle it, Atlassian provides us their support. Maintenance is not much of an issue with Jira.

The license model which we were on was a perpetual license model, which is the server edition of Jira, but that is being discontinued by Atlassian, which I can understand from their standpoint (in order to better compete). The server model means that we buy the license and we do not pay anything for the licensing part year-on-year. It means it's a lifetime license, but we do pay 50% of the license fee for the maintenance with the server. That is the recurring cost for us.

When we go into the data center model, which is the only on-premises model that we have, and the cloud offering from Jira, Jira Cloud, then you can see that both of them are subscription-based models. Data center is a yearly license, and as for the cloud, you can either pay monthly or yearly, depending on your requirements.

But this kind of licensing structure is actually a little heavy on the organization when it comes to the budget, I would say. The licensing which we had was a perpetual license with a year-on-year maintenance charge which we had to pay, which was half of the licensing fee.

I would rate Jira an eight out of ten.

Currently, we're using it as a tracking tool. It helps our development department operate more efficiently while enabling the business side of the company to understand and track things better. For example, if we get a requirement from the business side, they don't tell us the status of the current cover every time. So basically what we do, if we complete development or make it to the development phase, then we can change the status in Jira. If the other departments want to see the progress, they can go to the Jira dashboard. So this reduces the amount of necessary communication between the business side and developers. Developers can mainly focus on the development instead of having to answer questions from other departments.

When we get a sign-off for a management request, we must catch it in our email inbox. Now we can get the sign-off through Jira, and I've automated this. For example, we can get the Jenkins pipeline results for every build we create and have that result plugged into Jira. So when we run the Jenkins pipeline, the build is already automatically connected to Jira. We've been able to integrate the ecosystem we created using this automation tool. If you open Jira, you get the development tab there, so you can find out everything a company made under this Jira or what brand is created under this Jira. As a developer, I find this feature valuable.

Jira could be simplified and integrated more with standard corporate communications tools. Say, for example, we have one indication of Jira in Confluence. So if we type a Jira ID into Confluence, it gives us all the information about the Jira profile. I would like to see this feature integrated with email platforms so we can just put our Jira ID or Jira link into an email and get all the details automatically. This kind of integration and automation would be helpful. 

I'd like to see better note-taking capabilities so every user can get notes when someone provides comments on a Jira ticket. So if they don't want to provide the comments on the Jira ticket, they can get the personal notes in a Jira tool for every profile. It's not something for the business side, but developers can track what work is finished and what still needs to be done. Jira could integrate better with Jenkins, which isn't fully supported on the Jira dashboard yet. I think it would be good to monitor the build's progress directly. That way, we don't have to attach it. We can do it from the background. Some workflow customization would also be good.

In the initial phase, I was using Jira for development and testing purposes. A story was assigned to me, and I just changed the standards and everything. But in the past six months, I have worked with configurations, adding different workflows, and all the other features.

Jira is pretty stable most of the time. However, we have an intranet on our side, and sometimes there are too many users. My company currently has four different departments at the top level. Each of the four departments has fewer than nine Jira users. My current department has approximately seven or eight users. So there are times when Jira goes down, and we find it difficult to log in. But we are trying to increase the capability of servers. Other than that, it's working fine.

We have migrated to GCP, and we're using the internal cloud servers, so we can easily integrate Jira into a server if we want. Scalability is a matter of cost. We just need to present our management with a valid reason for increasing capacity, and if they approve, it's an easy process for us.

We had to call Jira support for help with integration. For example, when I was trying to integrate Jira with my GitHub bot, I had to provide a specific kind of access and then run some scripts to find out if I had enough available space. After that, it's a smooth process.

The Jira setup is a bit complicated because we're deploying it in our internal servers. So we have to manage a lot of things ourselves. For example, when the new version of Jira comes in, we have to patch our servers and update our certificates. And then, for deployment, we have pipelines that we need to trigger. That's not too hard, but the patching and upgrading can be complex.

If it's a smooth deployment, it just takes 30 minutes because we only have to replicate it on a different server. So currently, we have more than 20 servers. So every time we deploy, we create a replica on every server, which takes time because we have to verify that it's working. In total, it's about two hours of downtime in Jira, so we do this at night. 

Currently, more than 10 people are involved with maintenance. For my team, I do the deployment and configurations. But if there is some fundamental change or a serious bug, a separate team handles this.

I don't deal with the money side of things. I just specify the requirements and the company handles everything. We are using it for many tasks so it seems like the price is reasonable. 

I rate JIRA eight out of 10. I think it's a great tool. I have been working with this tool for the past two years and I use it every day.