Jira Reviews

Workflow configuration (escalation, workflow chaining, conditions, validators, post-scripting, etc)

• Enforce role- and group-based permissions re: who can drag tickets, and when, on the agile boards.
• Instill true SLA-based reporting and escalation to keep work moving seamlessly through the process flow.

• Workflow management
• User permissions
• Native reporting capabilities in workflow
• Ticket status, etc

6 years

No

No

No

The forums and online documentation have been fine. I haven't needed to escalate beyond that.

The forums and online documentation have been fine. I haven't needed to escalate beyond that.

At my previous company they used Assembla. I switched them to JIRA which is more open in its project sharing as well as far more configurable.

JIRA has been very simple to use, no issues.

I've always done the implementations myself.

As an enabler of process and procedures, JIRA's ROI can be measured in that regard. Because we treat it like a tool and not an end unto itself, I've never measured it separately just for JIRA.

Including all plugins in my last job, ~$15,000 and $7,000 annually thereafter. That was very plugin-centric, however, due to the complexities and user interface solutions I implemented. Other deployments have been less expensive.

Bugzilla and other bug tracking tools were on the docket. We ultimately chose JIRA because of its UI polish and wide range of configuration options. When JIRA added Greenhopper, now JIRA Agile, that made the choice very simple going forward.

Read the online documentation, know what processes and procedures you wish to implement first, and keep it simple. Workflows can collapse under their own weight if they're overly complex for the sake of complexity, simply because "that's just the way things have always been done". Simplify simply simplify.

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.

We are using it to organize most of our software development processes. 

Being a cloud solution, we usually have the latest version, but sometimes, we get a pop-up saying that there are some changes in a menu or some new features are there.

It covers most of the development process, and almost everyone uses it. We are using it for every role involved in the project, such as business owners, product owners, testers, developers, and DevOps. For example, the product owner defines a new feature, and then we take the feature and create stories and development, testing, or DevOps tasks. We then implement the new feature or changes to an existing feature. All the test cases and other things are in Jira. So, everything is done in Jira.

It is a very convenient tool. We can organize our sprints through scrum or kanban. There are scrum boards, and there are kanban boards. If you prefer scrum, you can use Jira. If you prefer kanban, you can still use Jira. You can create your kanban boards in a similar way as you create your scrum boards. It is very useful. It also seems to be very popular these days.

Its search and reporting can be improved. They are already nice, but they can be further improved.

I have been using this solution for more than 10 years.

Its availability is great.

We have different offices, and overall, there might be about 2,000 people. There are no issues with its performance or service. Almost all roles in our company are using this solution.

Other people have experience with Jira's technical support, and they are quite happy with their support. Personally, I never had a case where I needed any kind of support.

It is a cloud solution. It just requires licensing. Of course, some support would be required for all users of Jira, which could be in thousands. It might not be an easy task, but overall, I don't think a lot of time is spent on its maintenance and support. It is a very trustworthy service.

It is certainly a long-term solution for our company and for previous companies that I have worked for. They have these long-term term licenses, but I'm not sure if they really pay on a yearly basis. They are certainly using it for a really long period and for a lot of users.

I would definitely recommend this solution. It is very popular, and a lot of my colleagues have used it before. It doesn't require a lot of learning time. It is very good to use. I'm quite happy with the service. Of course, it can improve, but personally, I'm very happy with it.

I would definitely give it a good rating. I would rate it a nine out of 10.

We are using Jira for requirement and defect management. Not for DevOps purposes, only application development.

The dashboard and reports tracking and the setup updates quickly, I am very impressed with those features. Additionally, it is user-friendly.

The integration of Jira could improve. The solution should be able to integrate easily with other solutions, such as ERPs. There are times the solution can be slow and we have to reset it over and over again.

In an upcoming release, they should improve the user management features. For example, when I want to monitor a project as a CEO I do not want all the details but enough that I can understand. Additionally, these features should be accessible to me by mobile.

I have been using Jira for approximately two years.

Jira is a reliable solution for that medium-sized organizations. It's not for enterprise-level organizations, they have a long way to go.

The scalability has to be improved more because Jira currently is similar to a standalone solution with very limited integration. The integration with other products has to be more.

We have approximately 50,000 people using the solution.

We use our own IT department for the technical support of Jira.

The initial setup was complex.

We used to be on a perpetual license provided by our clients.

I would recommend this solution to others. Any new startup company can start with Jira immediately because it is now offered in the cloud.

I rate Jira a nine out of ten.

We are using primarily using Jira for the project and issue tracking mostly.

One of the most valuable features is querying because the jQuery function is very good. Additionally, we can create good designs very easily.

There are too many restrictions in Jira. In DevOps, you can access the dashboards easily, but in Jira, you should have more administration rights. In our organization, there are some restrictions on creating dashboards and other features. Everything should be accessible with all access rights for everyone.

Jira should allow you to create and develop pipelines easily. In India, we have to purchase them separately or integrate other data tools. All these tools should be in Jira.

I have used Jira for approximately 12 years.

Jira is stable.

In my experience Jira is scalable.

The technical support has been satisfactory but could be better.

I have used DevOps and the main difference between DevOps and Jira is the test cases. You can have test cases in DevOps, but not in Jira. This is what I have observed in my recent comparison. Jira has jQuery and it is far better than what they have in DevOps. There are some filtration and grouping settings in DevOps which I do not like.

The initial setup is easy.

Jira is expensive and a lot of people are choosing DevOps because they are cheaper, open-source, easy to use, and have basic licenses. Jira should decrease its price to be more competitive.

I rate Jira 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.

I use this solution for general issue management, software planning, and change management.

This solution is a one-stop-shop for issues and plans.

Issue linking has enabled teams to trace issues.

I like the dashboards and Kanban boards.

The development links to GitHub are critical.

The only thing that JIRA doesn't for us is release management in a way that I can create a list of versions easily.

Perfect for keeping track of large amounts of bugs, tasks queries and releases for fixes. 

The SaaS does the job it is supposed to: helps you keep track of your projects. What I like most is the ease of adding users and the obvious nature of what they need to do -  drag and drop is always a win. 

It is cross methodology so Scrum, Kanban... it doesn't matter, you can use JIRA.

I like how it shows the sprints remaining. Being able to instantly see where you are in a project and what is coming up is invaluable. 

Also, the ability to link a programme of projects is very helpful. I can see where all of the teams are with their individual projects but also how they fit into the overarching business plan for the year.

In reality, it's allowed me to raise and keep track of 700 tickets (bugs, queries, tasks etc) effectively. I can track what tickets are in UAT and which ones are coming out in the next software release. It's very simple. 

It allows all of those involved in a project, to see what stage their deliverables are (depending on what you allow people to view, they can see all deliverables from all teams)

Keeping everything in one central place with it obvious as to who is responsible for what, is a fantastic thing. 

It gives programme managers an overview of how a slew of projects are going. This also provides information for Exec meetings/Board meetings - visuals are always helpful to instantly show people what is happening with a programme of improvements.

Basically it allows me to see what is happening very quickly. 

I have no areas of improvement that I would push. JIRA does what I need - it allows me to assign tasks and to update my project. Any problems that I have found have been more to do with people entering with a lack of details - rubbish in = rubbish out. But that is the same with all apps.

I've used JIRA for over a couple of years, in three organisations, so I have some experience of how different places use it.

SaaS so nothing to deploy really. 

There's been the odd amount of JIRA downtime (not self hosted) and sometimes tickets that can't be accessed. 

I've not had need to contact the customer support team so I suppose that is a good thing.