Jira Reviews

We use it for project and sprint planning and day-to-day bugs. We also use it for documentation, engineering, and enhancements tickets and for creating the feeds, which are like new features.

We are most probably using its most recent version.

It has been very helpful for feature enhancements, release planning, and sprint planning. We have been using it for creating bugs, enhancements, and all the tasks for a sprint. It helps us in looking at the quality aspects of the product along with the volume, burndown rate, and a lot of other things.

As an engineer, I like that it provides you blocks to put in comments, code, etc. It helps in giving better information. 

It is very configurable, and we can do whatever we want. Jira dashboards are also good, and we use them extensively. We also use the tracking mechanism extensively. 

Another thing that I like a lot about Jira is that in the dashboard, you can plug the modules that you want. You can enable certain sections. For example, you can show trend history, open Jira tickets, etc. Some of the managers have created a dashboard for each engineer. So, it allows you to do all sorts of things.

There should be a way to look for specific comments. When we have thousands of comments on a Jira ticket, there is no way to look at the comments of a specific type. In the comments, if there is a way to put a tag, it would be helpful. For example, when there are a lot of lengthy discussions happening on a particular ticket, there could be a conclusion tag or something like that to indicate a conclusion. It would help in sorting the comments based on a certain category, such as conclusion. I should be able to tag a comment with something like ##dev_conclusion##, and someone looking at the comments should be able to expand all the comments and search based on this tag. Some of our tickets can go up to 100 or 200 comments, and it currently takes a lot of effort for someone to go through them. It would be good if there was a way to preview the comments.

We want Jira to be the single tool that people use. We lose a lot of information when working at the ticket level in Jira. We don't want to have discussions in Confluence and design docs somewhere else. Currently, we make some decisions outside, and we make some decisions in Jira, and there is no combined way. There should be a way to integrate documentation into this, and I should be able to directly update the documents. They can also incorporate a review mechanism for documentation. I should be able to assign a sub-comment to someone to say, "I'll respond to it," or I should be able to tag someone to say, "Can you please look at it?" We should be able to use a workflow. There should be some built-in intelligence where when there is a design document in a Jira ticket, the signoff should be done by certain people. Currently, the documentation is completely separate. If there is a way to get the documentation into this whole workflow, it would be useful.

I have been using this solution for seven or eight years.

Its stability is really good. There is no doubt about it. Sometimes, we have performance issues. That's mainly because a lot of people have standup meetings between 8 am to 9 am, and everybody is using Jira at that time. The number of connections is at a peak in the morning hours. If I was a Jira development engineer, I would be thinking about a mechanism to ease that. Other than that, it is pretty stable and reliable.

We didn't have any issues with scalability. We create hundreds of tickets every day. We have between 1,000 to 2,000 users across all departments. It is being used extensively, and its usage might increase.

I didn't have any contact with their technical support. We have a Jira maintenance team. We have a Slack channel, and if there is an issue, we send it there, and the team looks at it.

I'm not a part of the team that takes care of its deployment. We are a big organization, and I am an end-user of it.

I would advise having proper planning because you don't want to clutter your Jira. Without proper planning, you would go on creating a lot of labels and other things, which would be of no use. You need to do release planning and then accommodate things into Jira. 

A lot of companies have a separate release planning team, and then there is a separate Jira infrastructure team. All these teams should think and work together. Otherwise, everybody would be creating their own tags, which won't make sense. I might create a tag for daily bugs, and someone might create another tag for the same thing, which would result in cluttering.

I would rate it an eight out of 10. Jira is an amazing tool. There is no doubt about it. We have no thoughts of using any other tool.

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.

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.

The primary use case of this solution is to manage work, to distribute work to the teams, and we use confluence as a SharePoint for documents and to use AgileCraft.

This solution is easy to work with. It's easy to understand, and easy to navigate. 

it would be helpful to have a better tutorial for learning and to have a better understanding of what the features are and what they do.

In the next release, I would like to see better integration with other software. Many companies have a lot of peripheral systems. They have ServiceNow or they could have something else. How do they integrate your stories, your sprints, or if you have confluence, or SharePoint when you start using Jira? 

The challenge is when you have someone who is not using confluence, but they have SharePoint or ServiceNow.

How do we connect, or integrate our stories with Jira, so we don't have to have the information in three different places? 

The integration and integration threads would help Jira going forward.

I have been using Jira for more than one year.

This solution is stable. I haven't experienced any issues, it works fine.

We have approximately 100 users. It is not used concurrently. There could be anywhere from 20 to 30 users in a day.

We have yet to explore the scalability, but we hope that it is easily scalable. For us, that was the purpose of using this solution in our organization. We plan to use SAFe, a scalable scaler, scale agile.

I have not contacted technical support,

The initial setup was done by two local employees.

This an area that I would like to explore more from an admin perspective, on how to set up teams, what are all of the things we can do, and to set up the right way so that we can get the most potential out of the software.

I am not involved in the pricing. We have a sales team to procure our licenses.

I don't feel that price is an issue.

I have heard of many other solutions, such as Rally, but I have not explored it or compared it with Jira.

It's difficult for me to tell you everything that Jira has to offer when I am still learning. I am trying to educate myself to have a better understanding. I want to learn more.

I would rate this solution an eight out of ten.

We use JIRA for software development projects and the implementation of business workflows. Our company runs more than one hundred projects on a single instance server. Besides core IT projects, we have implemented business processes on dedicated JIRA instances to manage high volume (greater than five thousand issues per month) non-conformities for some business lines. 

Transparency of development projects, as well as approval processes for some business projects, has improved massively. Interaction of business units and IT happens very often via JIRA and considered to be very helpful. As many of our developments are requiring some level of compliance, the workflow and documentation of approvals are very handy. 

There is a very flexible configuration of "issues" and related life cycle. On top of it, the number of "add-ons" is overwhelming and of very good quality. I would consider the reporting capabilities to be the best feature, as ultimately the visibility of issues allows management of the projects.

My main concern is the administration of projects, especially user groups, and this requires root access rights but there is no concept of layered admin rights. Projects can be managed by a limited admin, but the creation of projects needs root admin rights. In decentralized project ownership, this gets tedious.

We used an open-source system called Mantis, which was considered unsuitable for use outside the IT world.

The setup of JIRA is straightforward.

To try this solution, use their cloud offering to get familiar. After that, it's in my view worth the money.

We went right away to JIRA without evaluating other options.

JIRA, its add-ons, and the Atlassian product world are already very powerful and it is difficult to name significant blank spaces.

This is a very powerful solution. Get some advice and training to make the most out of it. You may miss out on some of the capabilities if you don't.

Multiple features make this product a delight to use. Using this for backlog prioritization is the key to either kanban or scrum processes. JIRA does a great job of articulating the story and adding elements to the story to help in the prioritization. If you are overseeing multiple projects, it allows you to easily follow the teams progress.

Another feature is the ability to incorporate add-ons. It’s great to have for those one-off processes you need. For example, the integration with Confluence.

Working in a dev shop that is 100% scrum, this tool is invaluable in its insights to how the process is working. Are the stories written well? Is the team executing on the highest priorities? How is the team executing sprint by sprint? All these can be found easily within JIRA, either with their out-of-the-box reporting, or the ease with which search queries can be downloaded to CSV to manipulate in a data visualization tool.

The reporting out of the box is minimal; I would like to see a report-building capability out of the box. Teams have access to more than a dozen out-of-the-box reports with real-time, actionable insights into how their teams are performing sprint over sprint. Examples include Burndown, Sprint, Cumulative Flow, Epic , release, Velocity. However most will find these reports too simple and want some sophistication. Luckily Jira gives the ability to export results where you can work offline with them in a tool like Google Sheets, Microsoft Excel or other preferred data parsing tool. For additional spend you can purchase their reporting plugin.

I have used this application for approximately five years over several different roles: product management, development manager and delivery manager.

We deployed on premise. The amount of time to deploy was simple for a trained technician. Would highly recommend if installing on premise to shy away from any customizations in workflows; will make upgrades a pain in the future. If you considering using this, I would recommend the cloud option first.

No issues with stability.

Like any application installed on premise, you must be monitoring server and application logs to ensure the right level of performance. Scaling up is easy.

Most of their customer service comes from the community. Robust community of evangelists who respond rather quickly. As the application is highly stable, contacting customer service has been few and far between. Responses came thru within expected timeframes and were helpful, even if pointing to already published articles.

I would rate their technical support high.

I've also used Microsoft TFS (Team Foundation Server) for another development team that was .NET based. Used both Jira and TFS at the same time, though for different project teams.

Atlassian built their reputation on building applications that were easy to install and using a community model to improve. The setup of JIRA was straightforward, just as the documentation indicated. Us technology people have a hard time reading thru user guides, but these were easy and quick.

It was implemented by one of our developers.

Development teams, especially scrum teams, need some type of tool. For geographically dispersed teams, the ROI has a quick payback period, less than three months. Geography could be the dev team in one city and the product team in another.

Look to their cloud offering first; get using it quickly. Be wary of some of the add-ons, as there are cost components to them; if you need them, add them in.

As indicated above, we used Microsoft TFS. We tried to have a JavaScript team use TFS, but it didn't really fit into all the other ALM tools a JavaScript developer uses, so we quickly scrapped TFS and moved back to JIRA. The same was true for a .NET team; tried to have them use JIRA, but it was difficult to break the Microsoft eco-system. Not impossible in that case, just a culture shift you want to address carefully.

Review all your use cases for the tools to see if Atlassian matches up nicely to those you need; makes integration easier when all are from one provider. Be sure you understand what you are licensed for and what costs extra. For example, do you need portfolio management? Because, if you do, it's an extra cost.

I use Jira in my company as a project management and software development tool. We use Jira in our company to document all of our requirements and releases in relation to project management and manage the agile lifecycle management of our products.

The most valuable feature of the solution is that it is easy to use and allows users to use agile methodology. Jira also offers a lot of plug-ins, which are helpful.

I would love to have more free plug-ins in the solution since most of its present plug-ins are great. I want Jira to have more plug-ins, which will allow for more free plug-ins that help with the area of reporting.

I have been using Jira for four to five years.

It is a stable solution as it is a cloud-based product.

It is a scalable solution, but it comes with an extra cost.

More than 100 employees in our company use the solution.

My company has not faced any problems or issues with the use of the solution. That tool's use can be easily extended.

As everybody in the organization has a role in the use of the product, employees ranging from managers to developers use it.

My company has not faced issues with the use of the solution. It is very easy to reach out to the technical support team of the product if our company faces any issues with the product. My company just needs to schedule a call with the technical support team of the product, and they readily help us. The solution's technical support is good.

I have worked with some other tools in the past. My company chose Jira since it was easy to use, scalable, and pretty straightforward.

The product's initial setup phase was straightforward.

The product's deployment phase was straightforward, as one just needs an account to log in. As not many technicalities are involved in the product's deployment process, it is useful for project lifecycle management.

The solution is deployed on the cloud. Jira also allows users to opt for an on-premises deployment model.

There is a need to make yearly payments towards the licensing costs attached to the solution. The product offers flexibility in pricing since it depends on the memory bits you have used.

It is a perfect tool for those who want to manage the projects in their organization.

The benefit I have seen from using Jira is that it streamlines the development process. In general, the solution provides visibility and streamlines processes.

I rate the overall tool an eight out of ten.

We use Jira for project management and tracking. 

I want the tool to integrate connectors. 

I have been using the product for five years. 

Jira is stable. 

The solution is scalable. My company has 300 users. 

Jira's deployment is easy. 

The tool's pricing is reasonable. 

I rate the product a nine out of ten overall.