Jira Reviews

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.

The solution allows us to escalate issues from the end-user customer very easily. For example, if they're trying to access our PayPal page, and they're getting an error, we will do the basic troubleshooting. If the problem persists, then we will file the case and we will send all the stuff to reproduce the issues, including the ID, everything, using the Jira tool. We will create the task and it will go to the Level Three engineering team. They'll create that bug and route it to the Product Development team. Since the time I've raised the ticket, there are lots of options and there are lots of products that we may be using. That includes understanding what is the issue, what is the SLA, what is the issue criteria, et cetera. We can create and submit issues based on multiple types of criteria.

I can collaborate on issues that I've escalated very easily, even if they were escalated to different groups. I can segregate as well. It makes it easy to track bugs and issues. 

My experience with Jira has been great. Jira can track bugs and records improvements clearly. 

It's easy to escalate the issues to the product development team. 

It's not that difficult to create and file an issue. It is very user-friendly.

The ability to include attachments and assign reporters is great. We're able to easily delegate the task. That's extremely helpful. 

In every email, there is a way to track who is looking at a specific issue. If you look into Jira, there will be a crystal clear communication chain from the start to end of any issue.

In Jira, sometimes developers are not getting alerts when Jira is moving out of the SLA to the product development team. Or, for example, if you're sending a Jira ticket to me, I should get an alert if I've not worked on the ticket for a long time. I should always get an alert within 24 hours. For example, there should be three kinds of alerts. If a Jira ticket is raised and does not have any steps, for example, if I'm not assigned, it should be in green. If one day goes by, it should be in yellow. If the SLA is about to end, it should be in red. That way, I will know what needs to get attention. I'd be able to say "Oh, I should work on my task." There should be some color-coded alerts to keep me informed in a more visual way.

Sometimes I might get an attachment from the user through email that I need to download and save to my local desktop. What feature I would like from Jira is the ability to have an attachment field option open Outlook. Right now, when you click an attachment, you can only attach the items which are stored on your desktop or documents that have been downloaded. However, there should be an option to attach a file to a Jira issue directly from Teams or Outlook.

They should offer free online training courses to users. 

I've been working with this solution for seven years. While I joined the organization seven years ago, the company had already been using Jira for quite some time. 

The stability is good and the solution follows the agile methodology. We've never had issues with its reliability. There are no bugs or glitches. It doesn't crash or freeze. the performance is good. 

It's my understanding that the solution can scale. 

We have more than 5,000 people using the solution right now. They include IT specialists, product support, developers, product owners, technical lead, and architects.

I have not faced any Jira issues. I have not raised any tickets to the Jira team directly. It works very well.

The company may have previously used ServiceNow, however, as I recall, it is difficult to expand, and therefore the company has used Jira for quite a long time. 

I'm from technical support. I'm not a part of the development team and therefore have not helped implement the solution. Therefore, I cannot speak to how easy or difficult the process is. 

Jira maintenance is taken care of by the product maintenance team and the change management team. While we own the product, they respond to it. 

I'm not aware of the pricing or costs. It's not an aspect of the solution I deal with directly.

I am aware, however, there is a bit of a cost to do the online training.

We are using the latest version of the solution. 

You can use both cloud and on-premises deployments. Cloud deployments can be on various clouds, including Amazon, Microsoft Azure, et cetera. We are using GCP, for example. 

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

We primarily use the solution as an ALM, an application lifecycle management tool. 

I like the entire workflow customization, which we could set up for our usage.

There are some really great in-built reports.

The solution is stable and reliable.

The scalability is great.

In terms of the initial setup, the solution is easy to implement. 

We've had zero issues with the product. It's been great.

Even though I like the reporting part, we have some issues. I don't know whether there is a Jira problem or a test risk problem, however, sometimes, we face issues on fetching the reports. This is when in-between integration comes into the picture. There could be easier integration. It used to be easier in 2016.

We've been using the solution for more than three years now. It's been a while. 

The product is reliable in terms of performance. It's stable. There are no bugs or glitches. It doesn't crash or freeze.

The solution can scale well. If a company needs to expand it can do so. It's not a problem.

We have 250 or more users using the solution. We might go up to 300. It's not likely we would pass 400 users. We might increase the usage a little bit.

We've never had issues with Jira and therefore have never reached out to technical support. I can't speak to how helpful or responsive they would be.

We used to use TFS.

The product is quite straightforward, especially since it is on the cloud. It makes it very easy to set everything up.

We have three people able to deploy and maintain the solution.

We did not use an integrator or consultant for the deployment of Jira. We handled the process ourselves. 

We pay for a yearly license. 

We primarily use the solution ourselves, as customers. 

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

I would recommend the solution to others. It would be ideal if it offered better tool integration, however, other than that, we've never had issues. 

I use Jira for the development of different versions of software, upgrading it from one version to another, and developing and collecting specs for the new versions.

I like that Jira keeps track of time and is good for how it organizes.

Jira has a lack of graphical interface that maps the different cases to the space or in the project. For example, if you have a project that has a big diagram of component systems, people, and use cases, each of those Jira cases usually can be mapped to a specific location. This can be enhanced by a curve set of Jira, or a curve set of screens, where you can map on which pieces of the project you were working on at that particular screen. When working on the left side of the diagram, or the right side of the diagram, you should be able to request all those Jira that are related to that part of the project.

If a system has ten different steps of data flow and the components are clear. You should be able to map those Jira cases to different steps in the process. This would show you how a field or component is related to a location in the diagram. The diagram then would show all the cases waiting to be done or already done.

Jira works too slow, especially when you are in a big organization with thousands of users. It is also too slow when integrating with other components like SVN or with a built system. I would like to see everything that Jira does is under have a second response time.

I have been using Jira for about one year.

Jira is a stable solution, other than planned downtime, it has no downtime.

Jira is integrated with other components in our system, like the build and release systems. 

We use internal technical support.

I would recommend that an organization implementing Jira ensure that someone gets training both at the developer level and the project manager level. The developer needs to know what needs to be done, what are the components and why are they there. The project manager should join the training and determine if there is a relation between multiple projects to see that they are really integrated well into other components of continuous integration and continuous delivery.

Because of the slowness, I would rate Jira an eight out of ten.

The solution is primarily used in a scrum setting for creating all the features, topics, epics, stories, backlogs, and helps manage the scrum.

It's a very powerful product. It works well with Confluence. It interacts with it well.

There are very advanced features in Jira compared to, for example, ServiceNow.

You can record your unit testing, regression testing, UATs, et cetera. With a wider universe of applications, it's very flexible. 

I'm not totally a business analyst, however, a business analyst, can really, really use it very deeply due to the fact that you can register the results and create your test cases, run them, and document the results. All the testing is very advanced in Jira and it's very nice.

While it's very powerful, it's very complex sometimes. You can do many fancy things and have connections between features. With so many options, it's easy to get lost and it's not as easy to be on top of all the features and changes. In that sense, ServiceNow is easier to keep up with. Its configuration is more complex than ServiceNow.

The interdependencies between objects sometimes are not easy to trace back and to have a clear view of. That's why starting with small configurations is very important; we don't create very complex structures between objects in Jira. That said, sometimes when updating a history that was linked to an epic we would not understand why the epic didn't change when we changed the history. The relation sometimes can become complex. This is not a problem of Jira per se, it's a problem of how you configure Jira.

I worked with the solution for a while, however, I stopped using it. My last project was about 12 months ago.

The solution is stable. I cannot recall any issue with bugs or glitches. Jira never went down. It was reliable.

It is a scalable product. It can be applied with much more deepness, especially for developers.

Normally if I had some questions and issues on how to do what on Jira, I'd look for local support. We didn't have any Jira consultants or anything like that.

We also use ServiceNow. We use both products in the same way.

The configuration process is pretty complex. It's a pretty advanced product. You'll want to understand how to use it and what you want it to do before jumping in.

I would advise potential new users to start with simple cases in terms of configuration and to build on top of that in order to add complexity by identifying the need and not working from scratch.

I'd rate the solution at an eight out of ten. You need to get used to using it. It's a solution that can et very complex. 

We are using Jira mostly for the workflow dashboards for our projects. For example, for now, we are using the Kanban boards at team levels and also between team cooperation levels.

The links between tickets are very valuable and the boards I found to be configurable and usable.  The boards allow some level of extended configuration and they can be customized according to our project needs. Additionally, it is easy to use.

I'm mostly focusing on the requirements traceability with my thesis, the integration could improve for other tools. The companies are not only using Jira. For example, for the test cases or for the documents templates, we are using Polarion and we have been having some integration issues.

I have been using Jira for approximately four years.

Jira is easy to scale. We are implementing it for our team and for other teams, such as the relations teams. If you look at the different levels, such as the coordination levels, we are using it extensively on a daily basis.

In my team, we have less than 100 users using this solution but we also have other teams in our large company that could be using the solution. Our company has thousands of employees.

I have not contacted support.

The initial setup of Jira is straightforward.

We have a team in my organization that specifically handles the support of Jira.

The stability and performance are good, I have not had any complaints from people using Jira.

I would recommend Jira to others.

I have not used many tools to compare Jira with.

I rate Jira a seven out of ten.

My organization primarily uses Jira for project execution like managing the sprints, sprint planning, task creation and execution of the project on a sprint basis.

They also use Jira for other insights into how our team is performing and the velocity of the team. They look at the dashboard and report to see how are we delivering minimum viable products (MVPs) on time.

Jira offers tools for managing projects using Agile methodology. I think it is good to encourage the development team to use Jira, so that the organization benefits from the proper execution of projects on time. It helps our organization to execute in a better way.

I like the comment section. When you create a Jira task and work on it, sometimes product owners need to know the most recent status. I can go to the comments and then provide my updates stating how far I am. They can also refer to it and they can comment on it. It's for collaborating with other team members.

I also like using the filters in Jira. I can label all of the Jira tasks based on different business areas or whatever category I want. I can filter something that is related to what I've been working on. For example, if I am interested in APIs, I can filter all the Jira tasks with the API label and get all the API-related tasks, check the progress and where they stand. 

I can also get access to documentation such as the tester data and the other things that other developers have provided.

Jira could provide more insight into sprints such as how did we perform in the last sprint compared to other sprints. It would be helpful to have metrics and a dashboard feature for others to see. 

I have used Jira for the past three to four years.

In all the time I have used Jira, I have not had any stability issues. 

Jira is used by many of our teams and I have no concerns around scalability. 

There are around 1,000 users in my company who use it.

Jira offers Agile project methodology management and can be used for defect tracking and bug tracking. I would strongly recommend any organization wanting to use Jira, to work with the Jira team to understand what each product offers and how suitable it is for their organization. 

The Jira team could be consulted to understand the project, your department's requirements, and provide a proper way of managing the tool and advising what are the kind of roles you'll need.

I would rate it an eight out of ten.

I use it for portfolio countdown. I work as an enterprise architect in the company, and my usage of Jira is minimal. Software engineers in our company use Jira very heavily, but I do not use it for my day-to-day work.

Cadence management has improved with Jira bots.

Its visual display and ease of use are most valuable.

Sometimes, the status change is too difficult. The change of status is not configured correctly. We sometimes have a limitation on the number of changes that each workflow can do, so we get very restricted with the changes, and status change gets difficult. It could be specific to our implementation. 

Once a story is closed, all the records, versions, and documentation associated with it are gone. We lose the traceability of what was done.

Color codes are currently missing in Jira. It is very limited in that aspect. I would like to be able to color certain impediments or features in red. I don't want to look at everything ticket by ticket. I just want to be able to look at the colors and see where we are. I am not getting that in Jira currently. Maybe it is there, and I don't know about it.

It is stable.

Once we moved to the cloud, it became better. Its scalability should be good.

We have more than 2,000 users. It is extensively used, and we want to use it more and more.

We never had a similar solution because we were a waterfall organization. After we moved to the Agile methodology, we started using Jira.

I was not a part of its implementation.

We most probably didn't evaluate other solutions. For Portfolio for Jira, we considered other solutions such as Planview or ServiceNow, but for the software engineering development life cycle, we probably didn't evaluate anything.

When we cut over to Agile, it was a huge task to get everybody on the same page in terms of the setup and rollout. When we looked at each other's desktops, it looked so different, and our central team did a lot of effort in making it all look the same. I saw the full central team being pulled forward to resolve these inconsistencies. 

It is so open that it allows inconsistency. So, you need to have a very strong and resourced team for the initial setup, implementation, and training. Otherwise, it can just fail. It could be a good thing that it is open, and everybody can have their own Jira, but finally, when the organization wants some statistics on what's happening at the enterprise level, you will not get any data. So, my suggestion to anyone cutting over to Jira is to have a very strong and resourced team centrally. You should roll out, learn, and come back to it. You should repeat this process and keep on learning and coming back. It has to be a very strong cycle.

I would rate it an eight out of 10.