Jira Reviews

The primary use is task management. It has performed okay. It is easy to configure and maintain. It's quite simple to track tasks, then link with other applications/solutions from Atlassian, like source codes.

• Visibility
• Avoids emails and exchanging information in an informal way. 

I would rather have a tool that we do everything on. Also, we have access to end user policies where we can configure them and give access to the correct person. We have tracking of who works on what and why over the history of a project.

Workflows, because we cannot employ a different approach depending on the speed of the project or customer. Whether it's research, engineering, or maintaining the process, we can cope with processes easily without adapting the tool, but adapting the tool to processes.

There are no fields to search or to filter by, mainly the ones which use a data around a date and time when something changes. So, you have to use some add-ons and create a lot effort to obtain information from the tool. Thus, you have to adapt to the lack of search that the tool does not offer.

So far, so good.

I don't see any problem with it.

In the past, I had training from the distributors and it was okay. 

The tool is very easy to use. What is important is that we don't have to wait so much for contracts or more hours to have support. This is something that we have, and it is good for this solution.

Everywhere that I worked, we started by using spreadsheets, then we moved to some free tool, and finally to JIRA.

As far as I know, the initial setup was very simple and straightforward.

Understand your own process: What you are looking for, the size of your company, what your budget is, and the larger plans for the future. There are tools that scale better than others and there are solutions that fit to both small and big teams. There are tools which scale better for larger companies. 

Most important criteria when evaluating a vendor: 

• We evaluate the company's strategy.
• If they bought an legacy solution to add to the portfolio or if they are developing from scratch.
• What are their plans for the future?
• What type of support do they have?
• What is their business model? 
• Do they have domestic experience or not?
• Are they focusing only on a few customers, and the size of those customers?
  

We use JIRA for maintaining tasks and bugs. Overall, we love using JIRA because it performs very well with a lot of tasks and a lot of dashboards.

Having a tool to manage all your tasks and all your bugs is very useful for any company. We use it a lot to keep track, to see how our development is going and how automation is going.

We use a lot of dashboards and a lot of queries to search for specific bugs related to specific versions. Also, we can provide it to all of our users throughout the company.

The ability to change and rewrite tasks is valuable. You can add a lot of columns, change the owners and the change the components. It gives you a lot of flexibility between the teams.

I would like to see it connecting to Git. That could be useful. We use it for Stash, but I think there is one for Git also. I don't know if it's a plug-in that exists already, but that could be nice.

We have had no problems with stability. We're doing maintenance upgrades, but it has working well all the time.

We're not dealing with the scalability because we're not IT, but I don't think there is a problem with scalability.

We used Bugzilla but its UI was not as user-friendly. The end-user experience was very basic because it's a free tool. It's important to us that QA be able to track the issues and, of course, for the developers to be able to track all the tasks. So we're looking for the balance between performance of the user interface and the UI for the other workers in the company.

I would rate it at nine out of 10 because there is always room for improvement, but we love this tool and we use it a lot.

I would recommend JIRA. Compare all the tools for bug and task management. After that, you'll see that JIRA is by far the best.

The primary use case is task management within the team and the company, as well as version management and bug management.

It makes the work process transparent, visible to everyone who needs to know about the current state of the versions, and all that happens. It helps to communicate among different teams, like support, R&D, and QA. Everything is in one place and everything is communicated in the same form.

JQL, which is JIRA Query Language. I can filter all the issues, display the items as I want.

It's very flexible. I can define workflows and custom fields and dependencies between issues and projects. And every project can have a custom configuration with my fields, my names for fields, my validations, and my workflows. It's very customizable.

I'm using the old version. I haven't upgraded to the new one, so maybe a feature I would be looking for is already there. I don't know. Something I had been looking for was pasting screenshots into issue details, but this was already implemented in the new version. 

Better user management features could help.

I have no problem with stability.

I don't have problems with the scalability. I know companies that are much larger than just projects or teams, that are much larger than my current team, and they work with JIRA and it works well.

I used the support from JIRA several times and it was good. I had questions about licensing, I had questions about upgrading from an old version to a newer version.

When I am evaluating a product or vendor, I have some intuition about it. I see how the thing is built and works, and I go by my own impression. For me, that is important. And, of course, price and maturity of the product, along with flexibility, are important criteria.

I would rate this solution a 10 out of 10. It's an excellent product. It has already improved. It has good support. From the beginning, it was very smart and customizable and built well, works well. There are almost no bugs that I have discovered. It's a good product.

I just saw an advertisement on the street for a product called Monday.com. I read a few lines, a few words about it. I hadn't heard of it before that, but I understand it does something similar to JIRA. Obviously, I can recommend using JIRA but if you are searching for something else, the first impression I got from reading the home page of Monday.com was good, so maybe it's worth evaluating.

Overall, everything with it is great. I found it super useful, as it is customizable for different teams and users.

The following definitely need improvement:

• UI 
• Speed 
• Mobile app functionality.
  

It is consistently slow.

• Running agile deliveries with dispersed teams. 
• The projects were typical agile, changing requirements frequently.
• JIRA facilitated story management perfectly.

• Overall, it has good viability. 
• Relatively easy for everyone to pickup and use. 
• It improved communication, as it was a popular tool, and most people enjoyed using it.

Kanban board: The board is easy to use and visually impressive to non-IT users, who found it easy to relate to.

• Report customisation could be improved. 
• Out-of-the-box reporting is limited. It would be helpful if more customisation was possible.

We use it for backlog management, sprint planning, requirements management, Scrum, conducting Scrums, and all of our agile stuff.

It handles all of the issues that we need it to do.

It is very flexible, so we can do pretty much what we want with it. 

I would like integrated requirements management, so we do not have to buy plug-ins for JIRA, since it was hard to get requirements management for it.

It is stable.

It scales up well.

We have a team who administrates technical support. They handle this interaction with JIRA. Sometimes it takes a while to get a solution, but they solve everything. 

Before, we used a homegrown solution. 

Almost everybody uses JIRA nowadays because it is the most cost-effective solution.

I was not involved in the initial setup. 

I do know the initial setup was pretty complicated. The user interface could be better organized and easier. 

It does not cost that much.

We did not really evaluate anything else. All of the other products were way too expensive for our purposes. Also, JIRA is the de facto standard.

It is very capable, but also very complicated.

Most important criteria when selecting a vendor: reliability.

It's really for Agile projects with storyboards, and then defect management.

The performance has been okay.

It has improved the Agile process in our company.

A lot of people in the business work with this tool so when you are searching for a new employee you don't need to train them on this tool. 

The reporting and the view, from a story to a defect, should be improved in the next releases. For example, how many boxes are assigned to one story, or how many tests are run on one story, and so on. This is what I miss in the tool at the moment.

The stability is very good.

We are about 700 - 800, and it works. Not all use JIRA but in IT we are 100 people.

I have not personally been in touch with support, but I think the support is very good. I haven't heard anything wrong with it.

We have two organizations. One is development, and they work JIRA. And the other is the business, which is responsible for testing. At the moment, we are going in the direction of DevOps and more Agile, and we would like to merge our tools together.

The important criteria when selecting a vendor, in my opinion, are that the vendor should be flexible, cheap, and the support should be excellent.

I rate it an eight out of 10. It's easy to use. People can become productive with this tool in a short time, and it is really the right solution for an Agile environment.

A lot of solutions show very well on paper. When you are selecting a solution, do a proof of concept in the environment.

We run pilots and product development using this for Agile and Scrum applications, in mechatronic product development.

It has performed well so far. We like it, we would like to expand it.

It's a tool that won't change the way that you work, but it supports the way that you work. Agile is changing your teams, changing your organization, the way that you work, and then JIRA will help you doing that across multiple locations, for instance. 

We don't do physical boards. I run a team with four locations, in three time zones. I need to work with online tools, and this is where the tool helps me. It helps me to use virtual Scrum boards across four locations, three time zones, and to plan my work.

The most valuable features are 

• the easy handling
• drag and drop
• what you see is what you get.

It's, smooth, accessible. It fully supports the Scrum approach, and the Agile way of working, and it has Agile thinking behind it, so this is very much helpful.

I struggle with Epics, how they are implemented in JIRA, because they don't work like any other Story, in a good way. I see a list of Epics, but although I can order them, there are some mismatches with how the Epics are used compared to what Scrum expects, or what Story mapping expects an Epic to be. 

For instance, if I rate an Epic, the Story points, and I rate the related user Stories, the Story points, they all count together. They're all summed up together. So, the overall Story points for the Epic, including the Stories, is double of the Story points. It just doesn't make sense. Maybe I'm doing something wrong, but I had to delete all my Story points on the Epics because they were counted including the Story points. This is not correct, and I would immediately improve that. 

I would like to see visualization of release planning. I can list the releases and I can give dates to releases, but to show how they are happening on a timeline, I would need to order the Portfolio part. But just for this, it may be too much to use the Portfolio for that.

The stability of the solution has been near perfect. I haven't faced yet any technical interruptions. 

There was one issue we had, technically, when we added 30 more users. The server hung. I don't know whether it was because of the tool, or what the reason was.

Scalability, I can't really touch yet. We have small scale approaches. We are about to scale. I think the idea about how to scale is not yet clear. It works perfectly for a team, that is pretty clear. How you do this for more teams, I haven't investigated this too much. Maybe the tool contains this, but currently it's not fully clear to me.

We switched because the visualization is a great help. So, really to transfer from a physical Scrum board to a virtual Scrum board implemented in JIRA, as well as so teams can work with us, and collaborate with us, on a Story to produce a result. Recently we tried to work with PDC task management. As a team, we had to learn it. It's possible as well, but not as easy and flexible as JIRA.

I'm not the selector of the vendor, but from what I can tell, from what our IT selects, the vendor should be 

• available for global support, should be accessible in 24 hours, if there's a larger issue
• able to collaborate with large enterprises, which sometimes have different cultures, different languages
• able to integrate into the existing work environment - we have this tool, and that tool; the tool should fit into our tool landscape
• able to provide training.

I would rate JIRA a nine out of 10. It's not a 10 because it's inconsistent, sometimes, in how it acts and reacts, like my example with the Epics. But it's a high rating because it's user friendly, it's easy to use, you do not need much training on it. If you know how to work with Scrum, you can easily use it for your own work in a small team. For multiple teams, I'm not sure. I can't judge this because I haven't done this yet.