Jira Reviews

I use it to manage my scrum projects and some of the Kanban projects.

In terms of version, they have been updating it every three weeks. It is a kind of a sprint that they do, just like Google Chrome. So, there is no going back and forth. We use a cloud-based application. So, it is always the updated one.

The type of cloud depends on the client. I've been through all kinds of situations: completely public, semi-public, and private. If it is a public cloud, then it is directly from Atlassian. They are providing it. So, there is no middleware.

It definitely streamlined the process of managing the projects. Earlier, we had a system scattered all over the place. We had information in Excel, Microsoft Project, and some of the other applications that we have, but now, we have everything in Jira itself. So, we create user stories and groom the product backlog. We have kept everything in Jira. It is our single source for project information that anyone can go to. So, we could see a lot of transparency with Jira.

Overall, it is very intuitive. It is so lightweight and easy to use. It is easy to manage our product backlog and user stories, and it produces great reports.

It is good for single projects, but if you have to manage the portfolio level of the projects, they have a few add-ons that we need to buy and integrate. They can improve this part to manage it in a better way.

It is not capturing the number of hours for which each person has worked on certain things. We use many add-ons to let resources enter the time in the user story itself. We use an add-on called Tempo, but it is kind of a lousy add-on. It is not straightforward. Rather than helping us, it creates a lot of confusion. So, instead of looking out for the additional add-on, I would prefer to have the timesheet entered as a part of Jira itself. They are anyways capturing every information they could for each user story, and then we are able to break down all the task lists. For each task, we're also assigning a resource. So, while we're doing it, why can't they allow the users to enter the time that can be created as a report? Right now, we need to acquire the add-on, and the add-on is not great. It is not helping. The add-on is also not free.

There could also be some additional reports.

I have been using Jira for seven to eight years.

Stability-wise, it is very good. It is very lightweight. I have used other enterprise-level products to manage the same kind of scrum and Kanban projects and other projects. Other products have many enterprise-level features, but they're very slow and kind of hard to manage.

It is a cloud-based one, so I don't see much difficulty in scaling it. If you want to go from 100 users to 200 users, you will be able to do it without much hassle.

I've been doing a lot of consulting. So, I've seen from five users to the entire organization with more than 500 people using it.

I did contact them through email and discussion forums. I had a limited opportunity to work with them. So, I don't know much about their support.

Jira is a kind of the last one I settled on. Before that, I have used products such as Rally and VersionOne. These two are enterprise-level scrum and Kanban tools that are similar to Jira. 

I have also used Asana and Trello. Trello is lightweight, but I wouldn't call it equivalent to Jira. Jira has many features that not many solutions have. 

Most of the time, we are working with the cloud-based one. So, we don't have to set up everything. It is all there. You just buy a monthly subscription package. The workflow configuration, however, would be a bit difficult while you're trying to set it up. In addition, if you have to go down to the permission level, it is a bit different.

Workflow-wise, you need to plan well because once you configure it, you cannot often change a workflow. For each project, the workflow might be different. You might have a development team, a QA team, a configuration team, and a deployment team. When you start a task, you just need to make sure you are covering everyone. In terms of the workflow, you should know what would happen if someone is not there, and what are you going to do. So, you need to make sure that you are covering those things. Other than that, you need to know how much you are going to take care of the hierarchical level permissions. These are two primary things, and then, later on, you can relabel quite a lot of things in terms of how you're using the backlog product and user stories.

I would rate Jira an eight out of 10.

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.

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.

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.

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

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.

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.

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

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.

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.

We are using it for project management.

It helps everyone to be on the same page.

Its integration with Bitbucket, Confluence, and other related products that Atlassian owns is most valuable.

If CI/CD is integrated with it, it would be better. I've used Azure DevOps before, and it's nice to have everything, such as CI/CD Repos and other things, integrated. Jira has fewer integrations. Azure DevOps has an easier interface, and it has got everything in one spot. I don't have to jump around in different applications.

It should have more Trello-like features. There are some things you can do in Trello, but you can't do them in Jira, which doesn't make any sense because Jira bought Trello.

It looks pretty solid.

It looks scalable. I haven't seen any issues.

It is being used extensively at the moment in our organization. Currently, IT departments are using it.

I have not interacted with them.

I wasn't around during the setup.

It has a lot going on. They own Bamboo, but right now, we're using Jenkins. 

I have used Azure DevOps at another company. I would advise going for Azure DevOps because it has everything. You've got your DevOps, and you have your Repos. Everything is integrated.

I would rate Jira a six out of 10.

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. 

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. 

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.

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. 

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. 

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

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.

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.

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.

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.

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.

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.

I use the solution in my company as an ITSM tool. Our company's service desk and those working with the engineering team use the tool.

The integration between Confluence and Jira, along with Jira's ticketing system, is a valuable feature the product offers its users.

I opted for Jira since it was offering ITIL V4, and there seems to be a compatibility between ITIL V3 and ITIL V4.

From an improvement perspective, it would be better if Jira could offer more in the area of data analytics similar to what Power BI and Qlik offer to users. The tool currently lacks in the area of data analytics.

Jira needs to consider lowering its prices considering the competition in the market.

I have noticed a problem with Jira in the Philippines. In the Philippines, there are only a few companies that offer local support, which is alarming. In my previous company, when we requested support, basic support was not provided, and we had to schedule and deal with everything on our own.

I have been using Jira for around two years. I am a user of the solution.

It is a stable solution.

It is a pretty much scalable solution.

The solution's technical support is good. I rate the support a nine out of ten.

Positive

I have experience with ManageEngine and ServiceNow. If I need to deal with a project involving retail business, then Jira would be a poor choice because dealing with a retail business requires a tool to have an approach different from what Jira offers. Compared to ServiceNow, Jira is a bit better.

The product's initial setup phase was straightforward.

The solution is deployed on the cloud.

The solution can be configured within a week or so. If there are changes to be made in the solution, then it requires more time to configure it.

If I compare Jira's licensing model with that of other products, I think that the other products have a much better licensing model. Considering what is happening in the market presently, and as people are moving away from Jira and ServiceNow, more and more people have started embracing cheaper products in the market. I rate the product's price a four on a scale of one to ten, where one is cheap, and ten is expensive.

It is important to know that my company uses the free version of the solution since we are not a big organization. My company is currently looking into the configurations and other areas before going for the paid version of the solution.

Performance-wise, Jira is a good solution, but the problem lies in the part of its licensing area.

I rate the product's price an eight out of ten.

I am an Agile coach and consultant, and my clients use Jira to manage Agile teams, including tracking and gathering reports on performance at the team level as well as the team-of-teams level.

Since I work with different companies in my consulting work, there are different versions and implementations of Jira that I deal with. Most of the time I work with Jira on-premises, although I have worked a few times on the cloud edition.

In the near future, I most likely be using Jira Portfolio instead of the regular Jira because that will be my new responsibility.

I enjoy working with (and can recommend) Jira for a number of reasons. The best features are that it is friendly and provides good visibility. It's to the point and very effective.

When I start work with a company, one of the promises I give them is that they will get visibility, and very quickly at that. We are able to easily create boards and have the teams start work with story points. Then, we will make use of the Structure feature, which is another good feature that we get benefit from. 

In terms of the general Jira software, one element that is missing is budget management. Perhaps such functionality exists in add-ons, however. Once, several years ago, I tried to use one such add-on (the name of which I can't recall) but I dropped it because it was not effective enough. If we had this feature, I think we could provide the whole picture to top management.

I have been using Jira for about five years. 

It is stable. 

It's not scalable enough, in my opinion. To explain, I have a specific level of understanding of Jira so I am able to make specific customization to support activities at scale, but I don't feel like Jira is easily scalable out of the box. It's not always natural to scale up Jira without customization.

The technical support that I receive is not necessarily talking with any Jira support team, but rather it involves using the community's help from the internet.

On one hand, this avenue of assistance is quite good because I can often find answers there, but sometimes it's not enough. In these cases, Jira will ask to open a ticket and to vote on it so it gets priority. But it's frustrating because we might still not get answers, or we don't find anyone able to handle our issue for months or for years.

Overall, and for most problems, I think I have enough documentation so I can figure out what to do and how to do it. When compared with other tools, I think that Jira's documentation is clear.

I don't deal with licensing in my current consultant position.

For application lifecycle management, I can definitely recommend Jira and I would rate it an eight out of ten.

What I like most about Jira is that it's flexible. It has the flexibility to be configured for any company.

An area for improvement in Jira is that it's not designed for test management. To use it for test management, you need an add-on or several add-ons, e.g. the most popular is Xray, or you can add Zephyr.

An additional feature I'd like to see included in the next release of the solution is the check in and check out feature for the test assets.

My team and I are currently dealing with Jira.

Jira is a stable solution.

I find Jira scalable.

The solution is very reliable, so support is not contacted often, but they are responsive.

Deployment of Jira can be completed within a few days. The number of people you use for its deployment still depends on the company size, but on average, you can use from one to two people for deployment, per week.

I was able to evaluate Micro Focus ALM.

I'm at a professional service company, and I'm the manager, so I don't work with any solution, e.g. my team works with the solutions. My team works with Jira plus Xray, then Azure DevOps, and Micro Focus ALM.

Micro Focus ALM is a very powerful solution, because you can link from the requirements to the test plan and the test lab. In the test lab, you can aggregate the test cases that you want to execute, including defect management. You can incorporate all these into a release, and inside this release, you can have several execution cycles. I'm referring to the functions of all the assets, e.g. functional testing. Jira doesn't have versioning, compared to Micro Focus ALM, so you can have different and fresh versions of the same asset. You can do that using different names, but Jira is not as well-designed as ALM.

I'm rating Jira an eight out of ten.

I use Jira for user stories, tasks, bugs, track releases, track backlogs issues, burndown, and test reports.

Jira has helped our company because it is easy to track releases and deployments. It is easy to track which tickets have been done or are still pending and left to be completed.

Jira's most valuable features are ease of use, simple to understand, and highly flexible. Additionally, you can use kanban or scrum which is a benefit.

The reports in Jira can be improved, especially for test reports. I find it difficult to customize and integrate for different testing purposes.

The out-of-the-box version of Jira has minimal to no testing functionality. I have to use Zephyr to be able to track testing. The time logging is also not easy to use, or user-friendly.

In the next release of Jira, there should be test cases in the test reports. Better burndown and burnup reports should be enhanced. Additionally, the usability of time logging could be better.

I have been using Jira for seven years.

Jira is stable and reliable, we have not had an issue.

I have found Jira scalable.

We have approximately 50 people using the solution in my organization.

I use the solution extensively in my organization, I use it daily.

I have not contacted support from Jira.

When I came to this company I had already used Jira. Previously, I was using quality control from Quality Center and Azure DevOps.

The initial setup was straightforward overall. The process takes only 10 to 15 minutes. However, the setup could improve.

We did the implementation of the solution in-house.

We have two administrators that do the patching and maintenance of the solution.

I would recommend Jira to others.

I would advise others to be sure to do the reports correctly because there can be some challenges in reporting and in the testing phase.

I rate Jira an eight out of ten.