We just raised a $30M Series A: Read our story

Jira OverviewUNIXBusinessApplication

Jira is the #1 ranked solution in our list of top Application Lifecycle Management Suites. It is most often compared to Microsoft Azure DevOps: Jira vs Microsoft Azure DevOps

What is Jira?

JIRA has multiple deployment options to provide the flexibility your organization needs.

Cloud is a fully hosted service for customers who want to iterate quickly and have us take care of managing the infrastructure.

For customers who need to run our applications behind their firewall, we have Server and Data Center options. Server delivers greater capacity for a larger user base and gives you more control, allowing you to remain compliant with your enterprise IT, security, IP and privacy policies. For our largest customers, Data Center provides all the capability of our Server option, along with high availability, instant scalability and performance at scale.

Atlassian also offers premium support and strategic services for enterprise customers. Technical Account Managers are cross-functional technical advisors providing proactive planning and strategic guidance across your organization. Premier Support goes above and beyond our standard offerings to give you account-wide support from a team of senior support engineers.

Jira is also known as Jira Software.

Jira Buyer's Guide

Download the Jira Buyer's Guide including reviews and more. Updated: October 2021

Jira Customers

Square, Nasa, eBay, Cisco, SalesForce, Adobe, BNP Paribas, BMW and LinkedIn, Pfizer, Citi.

Jira Video

Pricing Advice

What users are saying about Jira pricing:
  • "I am not sure about the pricing, but I know its licensing is on a yearly basis."
  • "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."
  • "Jira and its solution off the shelf are cheap. It is cheap for startups."

Jira Reviews

Filter by:
Filter Reviews
Industry
Loading...
Filter Unavailable
Company Size
Loading...
Filter Unavailable
Job Level
Loading...
Filter Unavailable
Rating
Loading...
Filter Unavailable
Considered
Loading...
Filter Unavailable
Order by:
Loading...
  • Date
  • Highest Rating
  • Lowest Rating
  • Review Length
Search:
Showingreviews based on the current filters. Reset all filters
RobertCampbell
Product Manager at a insurance company with 10,001+ employees
Real User
Top 20
Great for collaboration, very stable, and extracting data is straightforward

Pros and Cons

  • "You no longer need to email people. You can mention them right in Jira and have conversations there."
  • "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."

What is our primary use case?

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. 

How has it helped my organization?

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. 

What is most valuable?

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.

What needs improvement?

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. 

For how long have I used the solution?

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. 

What do I think about the stability of the solution?

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

What do I think about the scalability of the solution?

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.

How are customer service and technical support?

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.

How was the initial setup?

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.

What's my experience with pricing, setup cost, and licensing?

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.

Which other solutions did I evaluate?

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.

What other advice do I have?

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.

Which deployment model are you using for this solution?

On-premises
Disclosure: I am a real user, and this review is based on my own experience and opinions.
Flag as inappropriate
VN
Senior PM / Scrum Master at a financial services firm with 1,001-5,000 employees
Real User
Top 5Leaderboard
Stable and easy to learn with good customizations, useful burndown charts, and support for a query language

Pros and Cons

  • "It was very easy to learn Jira. As a scrum master, I run daily stand-ups, and they are run directly from Jira. 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 also use Jira is for burndown charts, which give an indication of how efficiently the squad is performing. I also use the Active Sprints function and a feature called Planning Poker."
  • "One major issue that I, and even our business stakeholders, have noticed is related to Epic Link. When Epic Link's background color is a dark color, it effectively becomes unreadable. I wish there was a way for us to change the text color of Epic Link in the Issue Navigator view."
  • "There needs to be an easier way to capture a few metrics. 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."
  • "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. 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."

What is our primary use case?

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. 

What is most valuable?

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.

What needs improvement?

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."

For how long have I used the solution?

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.

What do I think about the stability of the solution?

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. 

What do I think about the scalability of the solution?

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.

How are customer service and technical support?

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.

How was the initial setup?

Its initial setup was not done by me.

What about the implementation team?

Its initial setup was done by Jira administrators.

What's my experience with pricing, setup cost, and licensing?

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

What other advice do I have?

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.

Disclosure: I am a real user, and this review is based on my own experience and opinions.
Flag as inappropriate
Learn what your peers think about Jira. Get advice and tips from experienced pros sharing their opinions. Updated: October 2021.
541,462 professionals have used our research since 2012.
Gesner Herard
Senior Principal Engineer at a consultancy with 1-10 employees
Real User
Top 20
A great centralized tool that has a good agile framework and is useful for day-to-day planning, task management, and work log efficacy

Pros and Cons

  • "The agile framework works well, and I pretty much live by that. Everything, such as sprint management, is laid out."
  • "From a very software-centric or a lead developer standpoint, there should be the ability to work at multiple levels. You have epic stories and use cases or epic stories and tasks. It would be nice to be able to have multiple levels of stories and multiple levels of epics work with it. It's lacking a little bit there, and this is the big thing for me because it makes it difficult to do a real sprint when you're limited to one story per epic. It's really hard to isolate tasks at multiple levels to match the type of use cases you normally do. That's the biggest difficulty. Other than that, they've been improving year to year, and every version seems to have a level of improvement."

What is our primary use case?

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.

What is most valuable?

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 easy to 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.

What needs improvement?

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.

For how long have I used the solution?

I've been using it since 2008.

What do I think about the stability of the solution?

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.

What do I think about the scalability of the solution?

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.

How are customer service and technical support?

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.

Which solution did I use previously and why did I switch?

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.

How was the initial setup?

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.

What about the implementation team?

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.

What was our ROI?

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

What's my experience with pricing, setup cost, and licensing?

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.

What other advice do I have?

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.

Which deployment model are you using for this solution?

On-premises
Disclosure: I am a real user, and this review is based on my own experience and opinions.
Flag as inappropriate
KV
Product Engineering & Operations Director at a tech services company with 10,001+ employees
Real User
Dynamic and easy to use but needs better API integration

Pros and Cons

  • "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."
  • "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."

What is our primary use case?

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.

What is most valuable?

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.

What needs improvement?

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.

For how long have I used the solution?

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

What do I think about the stability of the solution?

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.

What do I think about the scalability of the solution?

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.

Which solution did I use previously and why did I switch?

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

How was the initial setup?

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.

What other advice do I have?

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.

Which deployment model are you using for this solution?

Public Cloud

If public cloud, private cloud, or hybrid cloud, which cloud provider do you use?

Amazon Web Services (AWS)
Disclosure: I am a real user, and this review is based on my own experience and opinions.
Flag as inappropriate
DavidMason
Consultant at a pharma/biotech company with 10,001+ employees
Real User
Top 20
An easy-to-understand defect tracking tool with good capabilities and integrations

Pros and Cons

  • "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."
  • "It also works well with all the integrated tools that you buy."
  • "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."
  • "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."

What is our primary use case?

I'm overseeing the developments done in Jira. 

What is most valuable?

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.

What needs improvement?

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, at the software board level that reports to the system board, or at 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.

What do I think about the scalability of the solution?

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.

How are customer service and technical support?

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

What was our ROI?

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

What's my experience with pricing, setup cost, and licensing?

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

What other advice do I have?

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.

Which deployment model are you using for this solution?

On-premises
Disclosure: My company has a business relationship with this vendor other than being a customer: Partner
Flag as inappropriate
AO
Head of Software Solutions at a tech services company with 11-50 employees
Real User
Top 20
Flexible and very easy to set up but can get quite complex

Pros and Cons

  • "It's really smart how they connected these third-party vendors into their own marketplace. You can create and add apps. Anybody can do it."
  • "Pretty much 70% - 80% of the Next-Gen Projects features are still to be developed."

What is our primary use case?

We have a service desk for customers. We have the whole flow from customer feedback throughout, committing with a relation in the code in Bitbucket.

We have the tracking and tracing, including all tracking of the issues all the way from the customer throughout the JIRA prioritization in backlogs and sprint planning and connecting those through the actual code commit in BItBucket. It's all done through JIRA to the service desk issue and back again to the customer. The entire ecosystem is quite connected.

What is most valuable?

The best features depend a bit on the project going on. We have some project managers for the Classic Project setup and all the features that come along with the Classic Projects. 

From my point of view, the NextGen Project in the cloud solution is really easy to start up with and it's quite flexible in how you put up columns and move issues and tickets throughout the status and columns that you put up. 

It's really flexible. From the Atlassian point of view, I can see they are moving towards more and more Next-Gen Project handling. The features from the Classical Projects are being continuously rolled out towards the Next-Gen Projects. Of course, there's still lots of ground to cover.

It's really smart how they connected these third-party vendors into their own marketplace. You can create and add apps. Anybody can do it. There's some approval function or a step via the Atlassian team to be able to actually endorse your apps throughout their marketplace. However, it's very smart to have collaboration between the company and third parties. Whatever functionality is lacking, there's most likely an app for it. 

I've seen some updates and subscriptions where you can get newsfeeds if you subscribe. They are focused on making the solution as responsive as possible. For instance, they have enabled some features called Project Archiving. If you're done with some project work, you could choose to archive everything related to it. Therefore, it won't be upfront taking resources from your solution, however, you'd still have access to it in the future.

What needs improvement?

Pretty much 70% - 80% of the Next-Gen Projects features are still to be developed. It's my understanding that the reason they started doing the Next-Gen and changing up the whole dual-end functionality is probably because of how heavy and big everything was getting. It had gotten pretty complex within the Classical Projects. 

It's quite time-consuming picking up the Classical Projects. They've gotten quite heavy and it's hard to use them in a productive way. There are just so many settings and possibilities. It's very complex and time-consuming, however, on the other hand, it's got everything you need in terms of functionality.

For how long have I used the solution?

We've been using the solution for a year and a half now. It hasn't been too long so far.

What do I think about the stability of the solution?

The solution is quite stable. We haven't faced any stability issues.

What do I think about the scalability of the solution?

The solution is quite scalable. They also allow you to archive old projects so that they don't take up space on your product, and that can help you scale. You might need a specific kind of subscription in order to archive, however.

How are customer service and technical support?

I don't really have much experience with the technical support team at JIRA. I've been reading the community tickets mostly. Most of what I've been curious about, I've been able to find the answer myself via the community or the WIKI. 

You can communicate with other users, which is really smart. It allows you to discuss best practices effectively. At the same time, I would guess that some of the users there would be actual Atlassian employees that are commenting and guiding. Overall, the community space is quite helpful. Therefore, I haven't really had any issues or tickets or any need to connect with a technical team in Atlassian.

One of my colleagues actually had an issue when a new user was invited before he had opened his 365 email. He had not logged in to the email account. Therefore, when the invitation was sent from Atlassian or from JIRA, I can't remember exactly which module, but then there was feedback that this was not an active email account, which made Atlassian revoke the whole user. Then, when he actually logged into 365, he wasn't able to connect to JIRA due to the fact that the email had been marked as expired or not an active email. He sent the request to Atlassian and they opened up a ticket and everything was fine within a couple of hours. It was really quick. That I think is probably the only dialogue we've had with the technical support in Atlassian and it was pretty positive. I'd say overall we're quite satisfied with their level of support.

How was the initial setup?

The initial setup's level of complexity varies. If you use the Next-Gen Project, you can get it up and running in, I would say, five minutes. That part's quite easy.

You can also just subscribe and you can get the free version. I really like that kind of subscription that you can start with quite a few features available. You can get it started for up to five to 10 users without any cost. Then, when you start getting the ball rolling or the projects rolling, you have to actually insert your credit cards to both get features unlocked, and also to add more people to the projects and to the solution. 

If you want to, you can add on quite a lot of features and connect with the apps from the Atlassian marketplace. That's also a really nice possibility. You can just click, add apps and it takes about 30 seconds. Then you have added functionality injected to your solution.

What other advice do I have?

I would guess we are using the latest version of the solution as we're using the cloud solution. I'm guessing that it's continuously updated automatically.

I'd advise others to consider the solution. However, It depends on what they're trying to achieve. There are a lot of easier project management tools like Monday.com, for instance. It's a lot easier to get up and running.

If your vision is to become a larger software development company, monday.com might be something that is usable for project managers. However, it wouldn't be a good tool, at least how I've seen it, to connect everything together as we're able to do in the JIRA cloud with all the connecting apps. I would guess we would be able to integrate Monday to JIRA or something like that.

It's really easy to get JIRA connected to Confluence and Bitbucket and to have the service desk as well. That way, everything is in one place. Again, it depends, on based on where you're heading. If the company is looking for easy project management, there's a lot of tools that would be just as good as the JIRA. If you're looking to distributing the teams and connecting a whole ecosystem, then definitely JIRA is a good pick.

I'd rate the solution seven out of ten.

Which deployment model are you using for this solution?

Public Cloud
Disclosure: I am a real user, and this review is based on my own experience and opinions.
PO
Technical Lead at a mining and metals company with 51-200 employees
Real User
Top 5Leaderboard
An all-encompassing, project management solution

Pros and Cons

  • "With the help of Jira, tasks are less likely to remain stagnant for a long time. We always see them somewhere on the board."
  • "There needs to be easier integration with third-parties — personally, this is the biggest issue for me."

What is our primary use case?

Virtually every day we have our daily scrum. Our team gathers around the board, which has all the columns showing where the tasks are standing: requested, planning, ready-coding, review, etc. Together, we view one task after the other and update the statuses. It's really a focal point of the team to know where the work stands, and what's the progress of the work since the last time we checked.

Within my company, there are roughly 25 employees using this solution. We have a scrum master, who's the most knowledgeable person on the tool. usually, they're the ones organizing the tasks, creating new tasks, and then creating the report at the end of the sprint or the quarter. They're the person who's creating the reports, using the more advanced features. That's the scrum master.

There are the developers, including me as a tech lead. There's the tester. There are managers — once in a while we have to present them with some reports and statistics, so they know how much work is being achieved, but they don't have in-depth knowledge of the tool. It's really an internal tool, so the customer is not involved.

We're not expanding much at the moment. We've been expanding in the past year, but now things have slowed down a little bit due to COVID-19.

How has it helped my organization?

With the help of Jira, tasks are less likely to remain stagnant for a long time. We always see them somewhere on the board. Nothing gets forgotten — it forces the team to make a decision on every little task that is planned.

What is most valuable?

The way we can quickly see in which state a task stands — with everything classified by columns. It's easy to know who is taking care of what. For instance, if I want to know how busy the person in charge of QA is, I can easily see what staff members are working for him via a little face icon or a tower. I can see who is responsible for what tasks. The board gives you a quick summary of the workload of everybody on the team.

What needs improvement?

When a task is completed, it disappears and I don't know how to find it. If I want to go back in history to review an old task that we completed, I cannot find it. Unless you remember a keyword or a task number, it can be very difficult to find old tasks.

Sometimes, in the display, there is an overload of information that makes it very difficult to read. If there's too much information, it defeats the purpose. You have to reach a balance, and I think at the moment, there can be too much information.

Sometimes the interface is too crowded. It seems like the default option when you open a task is that everything is open and all of the menus are deployed.

There needs to be easier integration with third-parties — personally, this is the biggest issue for me.

For how long have I used the solution?

I have been using Jira extensively for one year.

What do I think about the stability of the solution?

Atlassian tools from the Atlassian suite are all linked together. We use GitLab. We wanted to integrate GitLab with Jira because whenever we create a branch in GitLab, for a repository, we create a branch to develop a feature or to fix a bug. Once the work is done, we have to merge that back into the master branch. When we do the merge, we name the merge and we enter a reference to a Jira issue.

It's easy after that. The person who's taking care of and viewing the merge requests can just click somewhere on a piece of information in the merge request, and it brings you to Jira, to the associated tasks. Usually, for each task, we end up creating a branch; it gets reviewed and merged back into the master. Once the review is done, it's ready to be tested.

That's our work procedure. Basically, the two tools — GitLab and Jira — need to be integrated with each other, but at the moment, there is a bug and It doesn't work. IT reported that problem to Jira or GitLab, but we have not heard back. 

There is a problem when it comes to integrating Jira with other tools, or other tools with Jira, there seems to be a weakness there.

What do I think about the scalability of the solution?

Adding more users is not a problem. We haven't tried to add a third-party or to integrate with a third-party, so I can't comment on that. 

We don't tend to use Jira outside of its purpose at the moment. It's hard to answer this because we just add or remove users; we're not trying to upscale it to a higher scope or anything.

How are customer service and technical support?

I go through IT for technical support. Except for that problem I mentioned, the integration between GitLab and Jira, we tend to find the answers pretty quickly.

Jira offers good technical support.

How was the initial setup?

I didn't help with the initial set up myself. Since we have web access, you don't have to install anything. It was already installed when I joined the company.

What about the implementation team?

Our IT team handles all maintenance-related issues. They don't necessarily know all the menus of Jira, all its capabilities, but they know how to deploy it.

What other advice do I have?

Have a training session before you begin using it. That tool is good for teamwork, but it doesn't replace a face-to-face discussion. Among yourselves and your teams, establish some conventions as to how you will describe your tasks — what criteria will be acceptable? Include a section for requirements, have a section dedicated to discovering your setup because the tool has its limits. It helps you organize your work, but it doesn't replace the self-discipline of the developers to stick to some team conventions — that's also really helpful to get the full benefits of that tool.

One of the main advantages is that everything becomes visible when you use this tool. When your work is done in full daylight, it's difficult at the beginning because you feel like everybody's looking at what you do — it's all visible. They can access the information through JIRA, but at the same time, you're not going to get stuck too long in your corner. The drawback is that you feel more like you are being spied on. It feels like you're working in an aquarium. Everything you do is visible. But at the same time, you're not going to get stuck on your own. Without this tool, it's easy to get stuck on your own.

There's room for improvement. Sometimes the window is too crowded and the integration capabilities need to be improved. Overall, on a scale from one to ten, I would give Jira a rating of eight.

Which deployment model are you using for this solution?

Private Cloud
Disclosure: I am a real user, and this review is based on my own experience and opinions.
Meryeme Bensouda
Global Client Support Operations Manager at kyriba
Real User
Top 10
Good UI, easy to trace tickets, and very stable

Pros and Cons

  • "This is our way of communicating with different teams. We are a global company. I am based in San Diego, for example. A lot of the BAs are based in Paris. The development team is based in Minsk. We absolutely need to be in constant communication and on the same page."
  • "Jira has recently updated their UI, but more can be done to make it even better."

What is our primary use case?

We use it to trace our business needs development.

We have some nice dashboards out there where we can track needs for clients or track internal projects.

How has it helped my organization?

This is our way of communicating with different teams. We are a global company. I am based in San Diego, for example. A lot of the BAs are based in Paris. The development team is based in Minsk. We absolutely need to be in constant communication and on the same page.

With the time differences that we all have, it is very hard to kind of get on a call and centralize the information in person or during meetings. This solution makes it possible. 

What is most valuable?

One of the most valuable aspects of the solution is the fact that everything is traced on one ticket on Jira. We know exactly what has been done and what is left and we share the same feasibility we are assigned. We don't have to wait for team updates or emails or calls or even reminders. We just need to look at the same ticket and we know in real-time exactly what is happening. Without Jira, I don't see how we would be able to manage and trace in a very consistent, effective way.  At least, not across all of our development initiatives.

I have never been trained on Jira, to be honest. However, it's easy to navigate. Even for somebody who never is on it, it's very simple to pick up and understand. The only caveat is that when you get a bit more in detail, or you have some business requirements, you don't have documentation that you can just go and consult to enrich your portal or access.

One aspect of Jira that is very nice is that we are able to integrate other tools that our company is using. For example, we do use Salesforce for our support team and that's linked to Jira. Slack, as well, is also integrated into the system. It makes everything so much easier.

What needs improvement?

Jira has recently updated their UI, but more can be done to make it even better.

One thing that is missing is notifications that we can send out in an automated fashion so that we don't have to log into Jira every single time. We do have dashboards on our navigation pages, but we need to log in to see the current status. I can't just click reports every once in a while to trace or track projects, I have to log in to see. I'd prefer it if the data automatically came to me instead of having to go seek it out. 

It's possible the dashboards and the reports are something that can be properly configured on our end. However, I'm not the Jira administrator in our company. I probably just don't know how to do it. Jira may actually be able to trigger these kinds of reports. However, if they don't have this functionality, it should definitely be added.

For how long have I used the solution?

 I have been using the solution for four years now.

What do I think about the stability of the solution?

We've never experienced any downtime with the app. I can't recall any bugs or glitches. There haven't been any crashes of any sort. It's very reliable.

What do I think about the scalability of the solution?

I would say the solution is pretty scalable. Every single project team in our company uses it. Our staff, our BA, our developers. We do also have DevOps teams using it. Everyone uses it for different purposes. Our company, over the past ten years, grew exponentially. We've tripled our size and we never had any downtime with Jira. 

We have business owners, developers, quality testers, business analysts etc. on Jira. We have internal consultants from professional services teams, who trace the needs as well so that they can transmit information to their clients. All the top management personnel go to Jira to consult the dashboards as well. If they wish to trace the progress that their teams are making, they can do so. The solution is basically used in every aspect of the company, and as the company grows, so does the usage.

How are customer service and technical support?

I've never had to reach out to technical support, so I can't speak to how they are.

Which solution did I use previously and why did I switch?

When I joined the company, we already had Jira. 

How was the initial setup?

I wouldn't consider it complex at all.

What about the implementation team?

I wasn't here at the initial setup of Jira, however, in our company, we have a Jira administrator. Whenever we have a project to review and need to know how it's laid out and how we can place them better, etc, it goes through this person. She analyzes the needs and does it for us. 

 She knows the tool pretty extensively, but we don't rely on external consultants to do it. We have somebody from our company who does it for us and acts as our own Jira professional. They would be the one that basically helps you with the setup for your project needs.

What's my experience with pricing, setup cost, and licensing?

I don't handle the finance side of our relationship with Jira.

Which other solutions did I evaluate?

As far as I know, no other solutions have been considered as we've been pretty satisfied with this tool. 

What other advice do I have?


I'd advise other companies to go for it and try using it. Jira is one of the biggest players in the market. It's a scalable solution and very user-friendly. The onboarding is quite simple. I have never been trained and I've been using it for the four past years. Whenever there is a new release on Jira, we get a guide, which is helpful, and instructions as we use the latest version that comes in the form of pop-ups on your screen. If you want, you can just disregard it, but once you discover them, you can just hover over with your mouse and you can see the new features. If an organization is looking for something that will be easy for its workforce to adapt to, Jira would be a smart choice.

With the communication and the bridges that we've established with other tools, it's helping other teams get the information they need without having to get the Jira license or get them to go onto Jira. They just need to find their tool and they get the update from Jira in real-time.


Which deployment model are you using for this solution?

Private Cloud
Disclosure: I am a real user, and this review is based on my own experience and opinions.