JIRA Service Management Reviews

We are only using JIRA Service Management for a limited amount of use cases.

The most valuable feature of JIRA Service Management is a plugin we are using for the front end for simple user forms.

I have been using JIRA Service Management for approximately two years.

For the environment, we are using JIRA Service Management for it is stable.

JIRA Service Management is able to scale to a reasonable size. Since it is hosted in the cloud there are not any scalability issues.

We have approximately 500 to 1,000 users using this solution.

We are using the premier support from JIRA Service Management.

I rate the premier support from JIRA Service Management a five out of five.

I rate the standard support from JIRA Service Management a three out of five.

The initial setup of JIRA Service Management can be complex for new users. There is a lot of configuration.

We have a two or three-member team that does the maintenance for JIRA Service Management.

The price of JIRA Service Management could be reduced.

We did not evaluate other solutions prior to using JIRA Service Management. The company preferred this solution.

I rate JIRA Service Management an eight out of ten.

Our primary use case for this solution is project management. We use it to record some of our tasks and follow up with our developers to ensure they complete assigned tasks. It is cool and user-friendly. It is easy to navigate and understands most of its functionalities. Additionally, we use it to review developers' tasks and tasks assigned to the QA team from JIRA Service Management to run checks. When we're done with the checks, we do our reports on it, and the project manager can view what has been done. It is a very cool tool, but I didn't work with it for long before I moved to Microsoft Azure Dev Tools.

I can't specify which of the functions are my favourite, because I think everything about it is great. The only challenge is that it is difficult to navigate if you don't have any prior knowledge of the software. However, if you have knowledge, you can navigate around it and know what each tool within the software is used for. I preferred JIRA Service Management before we adopted Azure because I had already started getting familiar with it.

I think it's well organized. If the project manager knows how to set it up, it can be set it up in a way to suit what we want. The only issues we observed are network related, for example, when we try to log into the system or open up the software. Other than that, I don't think there is any other thing I can say that is wrong with the software. The developers did a very good job of knowing what the users wanted. The product is not lacking anything that a QA will want to use because it's not a major testing tool for QA. However, if they can develop their own JIRA development tool, that will be cool, similar to how we have Chrome development tool and Azure. I think it will be good if that can be incorporated into JIRA Service Management.

We have been using this solution for about five months. First, we used the latest cloud-based version where we navigate to the website and key in our community, company name, projects and group. We can then go directly to our workspace, where we see everything we do.

Most software work with the internet. Some of them, especially those that are cloud-based, are also linked with work servers, but there is no guarantee that they are 100% stable. If the network is not stable, then it affects the software. For example, if you open the web browser and type the URL and get a server error, it's usually a network issue. If the network is stable, the platform will work fine, but if it's not stable, you're going to expect some hiccups in the work site.

The scalability depends on the organizations using JIRA Service Management. If it's fitting for what they are using it for, then it's okay. If it's not, they have every right to change it and use something else. We decided to move away from JIRA Service Management to Azure because we felt it wasn't properly organized. I found working with JIRA Service Management interesting because I could look at the extractor and see which task is in development, or emerging, the status of every task and to who it was assigned.

Our company has currently switched from using JIRA Service Management to Azure.

I don't have any details of the initial setup process. 

I don't know anything about the licensing costs. I wasn't with the company when it was installed, and I only used it as a tool for my work. Hence, I cannot comment on pricing.

I rate this solution a ten out of ten, as it does not lack anything. My advice to users is that JIRA Service Management is a good project management tool to handle projects respectively and efficiently. The product is second to none if they know how to use it. Additionally, JIRA Service Management has a learning section where you can go and learn how to use the software. New users to the platform can also capitalize on a cursor feature that describes how to use a particular tool once you hover over it. For those who developed the software, I want to give them a thumbs up as they did a very good job. If there is anything they feel they can add to make it more user-friendly, they should ensure that the users can have access to whatever they want to upgrade on the software and let it be that the users can use that tool effectively. However, the tool could be improved by including more explanations to assist users who are new to the platform. I would describe JIRA Service Management as being 75% user-friendly, but it would be great if it could be 90% user-friendly.

We use it to track software development projects.

We get software developed faster.

I like that it's easy to set up Sprint and put tasks and stories into Sprint. It is really easy to lay out the work that needs to be done.

I think that either a Gantt chart or a calendar view is something my management is used to seeing, and while they like the Sprint burndown charts, they would still like to see what is on the plan, and what is up and coming. I would like to see improvement in the ability to filter completed tasks.

I have been using JIRA Service Management for three years.

The stability is ok for our needs. There are times when there have been some flaky things, that I don't think we expected, but it's not crashing all the time.

It seems to scale just fine.

I haven't figured out how to find Jira's technical support. There are times when I would have been happy to have had Jira technical support and I could not figure out how to get ahold of them.

There were some pieces that were more difficult than I expected. This is another place to think of some improvement. Not regarding the installation instructions, but more guidance on the different ways to set up your project and different ways this tool can be used. Again, if I'm paying for the licensing of the tools, going out, and sending lots of people to large training courses, this becomes more expensive. I'm looking for the developers to give more guidance on directions on relating to the tool and the ways that the tool is useful. 

I would rate JIRA Service Management an eight out of ten.

We use this solution to track the work of different team members and to ensure that project tasks get completed. They get assigned tickets relating to those project tasks and and a deadline by which they have to complete the tasks. As they make progress, they update each task in the Jira ticket and this keeps everyone in the loop about their progress.

We have an Agile environment and using Jira makes it easy to adhere to Agile best practices. 

It would be useful to be ale to link tickets across different gantt charts in Jira and Confluence.

I have been using this solution for two and a half years.

This is a stable solution. 

This solution is very scalable. We have tons of people across different companies using it. 

I would rate this solution a nine out of ten. 

One use case is to communicate with customers. We have a lot of customers who are facing issues with products and they can raise the request from the customer portals. Internally, we'll also use it for the IT team and the Jira team. If any configuration changes or any new projects need to be created, or any configurations to be implemented, et cetera, we have a service management project and they will raise their tickets.

The SLAs are great. With SLAs, we can try them out. If you are providing solutions or responding to customers, it's great. 

The flow of the reports is good. I don't see any features or anything that is lacking. Everything is good on the JIRA Service Management, in terms of what they have provided.

It's easy to set up.

We have a lot of add-ons, however, instead of the add-ons, for example, cloning could be better. 

When we do a clone of a particular issue, it needs to ask certain things like system fields at least, to copy them or not. One thing which I did not like, is whenever we are moving a request from one project to another project, if, during that time, for example, a resolution has been fixed and now I am moving that issue to a particular work in progress status, during that time the resolution needs to be clear. JIRA applications are not providing the information. It is not clearing it in the backend.

If we are moving from one issue to another, we are waiting for support to resolve them. During that time window, a resolution is mandatory and it is not prompting us to resolve anything. Due to this, sometimes the reports might not get properly recorded.

I've been using the solution for the last four years. 

Recently, in the Jira cloud, we have had an issue. Users are not able to log in and some of the customer data has also been lost. Overall, it's stable, about 99% stable.

Currently, the number of users on Jira Service Management is around 300 plus users - maybe as many as 400. In terms of Jira software, we have 1400 using it.

It's a scalable product.

We do have plans to increase the licensing in the future.

Technical support has been helpful. We are satisfied with the level of service. 

The implementation is straightforward.

I wrote the automation. I used automation for the Jira app, and in the backend, in the workflows. I used a validator with the script. Based on that, I pulled some conditions. It was easy.

I'm not aware of the exact pricing. It's my understanding that, compared to Service Management, the price is a little higher, however, the Jira software price is okay. It's a good price.

I'm just an end-user.

We are on the cloud, and therefore using the latest version. They release new versions and fixes automatically and we can take advantage of them right away. 

Others need to be aware of how we need to use service management first. They need to know the queues and the SLAs. They need to understand the configurations also. 

I'd rate the solution nine out of ten.

In our bank, we use a partner company who develops software for us. They use Jira for the developer portion to track issues, or bugs, that need to be fixed on the software development life cycle. 

We have two teams, one is the development department which includes developers and business analysts who use Jira to track and develop issues within their own team and a third-party consultant. The other is the audit team who is using Jira to track their audit findings and follow-up.

Jira's issue tracking for different projects for the development side is quite useful.

With respect to our help desk, we have been considering switching from ManageEngine to Jira so that we can have a single consolidated system for all the development life cycles. Jira has different modules that can develop workflow for demand management and project management, but the solution is no out of the box and would require lots of customization. The cost of switching has prohibited us from moving ahead with Jira as a service desk solution.

I have been using Jira Service Management for almost 5 years.

Jira is quite stable.

We haven't used Jira on a large scale. Our work groups are a maximum of 20 people.

We currently are using ManageEngine for the service desk solution. This solution has been good but they do not have a consolidated system for the development life cycle. We would like to switch to Jira for this service solution as well but cost prohibits us from moving forward.

The initial setup is not complex. The deployment itself does not take much time, however the custom workflow does take longer. 

We completed the installation with the help of external consultants who are familiar with Jira.

Jira is becoming quite popular and is well supported. We find that when working with other companies on other projects, they are using Jira to track issues so it is beneficial for us to use the same solution.

Jira has lots of modules and integrations, however too many makes licensing difficult to understand upfront and becomes quite expensive to have a full solution.

I would rate Jira Service Management a 9 out of 10.

We are a software development company with 80 users. As part of development, we track the sprint to see if all the storyboards are complete and development completion. We notify the development team about change requests or incidents using JIRA Service Management.

In software development you need to handle case related software issues, JIRA has helped us with that.

I find the Kanban chart where we put each story in to be the most valuable feature. We use the Kanban chart to revise the project every morning in our five-minute meeting.

JIRA Service Management should make reporting easier. I would like something integrated with DevOps tools.

I have been using JIRA Service Management for two years.

JIRA is a very stable solution.

The solution is scalable.

Once the system is integrated we look at the tickets and find the solution in-house. Someone from JIRA will contact us and offer a solution, but rarely will we request support.

We moved from HP Service Manager to JIRA Service because it was more suited to a software development company. We needed something to support our agility model where other software is focused on operations.

We used an integrator to deploy JIRA. The initial setup of the solution was simple and transferring to JIRA Service took about 3 months.

Switching to JIRA provided a financial ROI. We did the ROI study when deciding to move from HP Service Manager and determined it was beneficial.

If you are a software development company you need to use JIRA because it aligns with project management.

I would rate a JIRA Service Management a 9 of 10.

Most of the use cases were finding solutions to customer problems and SLA cases. We worked with customers on some cases like call centers and with some companies who would like to solve their customer's problems. We also worked with the banking industry and insurance industry.

I have worked at OBSS, which is one of the biggest software companies in Turkey. They were also one of the Atlassian Solution Partners in Turkey. I recently left that company.

Compared to other solutions, Jira Service Management is really reasonable regarding price and speed. Technical support from the Atlassian agents is great.

In the Turkish market, the biggest problem is that they are looking for a server type of solution, but when it comes to Jira Service Management, Atlassian is a remote type of license. There are just two different options, data center and cloud.

When I was working at that company, we started to work with Central Bank of Turkey. We also worked with the defense industry. The biggest complaint was about data privacy. If Atlassian opened a data center in Turkey, that would be a very good solution for these kinds of companies.

Some plugins could be implemented into Jira Service Management, like our plugin. We had our own plugin calculated each status and how much time the company spent in each status.

I have used Jira in the past 12 months. We were using the server type of license. I don't remember the exact version we used, but I have also used the cloud version of Jira Service Management, which was called Jira Service Desk in the past. I used it for more than three years.

The solution is stable.

There were three or four people working on maintenance, but their work was not only in Atlassian. They were working as system engineers. This is one of the responsibilities of maintaining Atlassian products and services.

The solution is scalable. The data center's most popular feature is being scalable.  The cloud is very fast, and setting it up is very easy. 

Our company had around 500 people, but after I left the company, it was around 700 or 800 people.

Technical support is good.

When we created a ticket on Atlassian, they were also working SLA services, L1, L2, L3, and L4. When we created a ticket, we were getting very good service from an agent. In some cases, we had talks with our channel manager, especially about the cost of licenses.

We previously used Confluence, Puppet, Bamboo, and HipChat, and then it was sold to Slack. We used Fisheye and Crucible as well. We were using most of the solutions regarding Atlassian. In my daily life, I have also used Trello.

I worked mostly as a business developer, but when I received feedback from our deployment staff, they said it was not difficult to deploy the solution. Cloud is very easy to use. You just can start to work with it.

The license we use is on a yearly basis. As a Solution Partner, we were using the free one and were using the free plugins. We were also giving our own plugins to the Atlassian Solution Partners for free. We don't pay anything to Atlassian.

I would rate this solution 9 out of 10. 

Sometimes the beginning of the implementation and working with custom-built workflows was a little bit difficult for regular companies. At this step, I strongly advise that they work with an Atlassian Solution Partner.

Specific industries need specific solutions. Atlassian partners have a lot of experience, maybe in that specific country and in that specific company field.

Our primary use case is for customer service and customer requests. We also use it to set SLAs and as a general help desk. We are customers of Jira.

The solution has improved company functioning by providing more transparency, in my opinion. Our business is already working out of JIRA, so it connected directly with the platform rather than requiring us to move between several different platforms.

The reporting is a great feature. I also like being able to create customized forms which is extremely helpful.

If you raise a ticket with Jira, the portal doesn't enable any capability to see your other JIRA tickets, only the parts that are in the plugin for the service management. That's not a great experience because we have project teams that work out of their own Jira backlogs, so unless it's a link to a ticket in the JSM, there's no visibility for the customer in one single location.

I've been using this solution for two years. 

We haven't had any issues with performance, other than issues related to being on-prem. It's a stable solution.

The biggest issue is not being able to display linked issues and that makes scalability painful as far as the customer experience goes, and weighs down the system with more tickets. In terms of expanding, it's fairly straightforward. We have over 5,000 users in various roles including managers, developers, HR - it's across the board. In terms of maintenance, we have the main administrator and then a couple of guys that help out.

We transitioned from Salesforce to Jira Service Management mainly because a lot of our teams were already working out of Jira for their own project tracking. It just allowed us to bring everything together rather than working in different systems.

The initial setup was fairly straightforward and was carried out by an in-house team.

I would suggest looking into your current layout and requirements, evaluating them and then figuring out the best option in terms of how you want things categorized and broken down from both a customer perspective and a backend perspective before you try to build it out.

Despite the few downfalls, its cost is still very good compared to other holistic systems. A big reason for getting the switch approved was that the cost was substantially lower than other solutions. I can't speak for the cloud experience, I'm sure it's a little easier than running on-prem, which is very administrator heavy when you want to do a lot of automation or post functions. It's important to be prepared for that. Depending on how your organization is set up, you're likely to need your admin to do those things.

I rate the solution seven out of 10. 

We are using it for internal issues related to our ERP system. We are tracking these issues and, more importantly, linking them to development tasks. So, if we've written an extension and there is a bug, and somebody opens a help desk case with it, we can link it directly to a bug ticket in Jira. We then know when this bug is fixed.

We are cloud-based, so we are always on the latest version.

The biggest thing is integration. Instead of having to have requirements in Word and then issues tracked somewhere and development tracked somewhere, everything is now in Atlassian. So, we've got requirements linked to development cases and the help desk tickets linked to development cases and tests.

The links between the help desk and Jira issues and between Confluence and Jira issues are most valuable. I can write requirements in Confluence and link them to user stories in Jira and test cases. I can see my test coverage and all that kind of stuff. The integration between these three is very useful. 

It is pretty customizable, and it integrates well. There are a lot of add-ins and a lot of connectors to third-party products. In my last company, we used Test Royal for managing all the tests, and it integrated perfectly with that. For any issue or bug, we could see what tests have been run and the complete history of the tests.

The way it handles subtasks can be improved. We would really like the ability to have different types of subtasks. If we have a user story for a feature, we would like to have a subtask for documentation, a subtask for requirements, a subtask for development, and a subtask for testing. Right now, we just make four subtasks, but there is no way to specify their type, so we have to add a custom field to specify what type of work is this. It just means you've got to look at more data. 

For logging time or time tracking, we would like to have something using which we can define the work type we're doing. We would like to log whether we're working on a bug, a new development, scope change, or rework. We've got a user story for which we do the dev, and then we have to do more dev. It is the same story, but some of it could have been a scope change, and some of it could be a rework because we either screwed up the first time or missed something obvious. Currently, we have to have a custom field and track that separately. It would be nice to have some kind of work type for logging time.

I used it in my previous company for about three years, and we literally just started with it the last week here.

Its stability is very good. So far, I've got only one issue in Confluence. When I'm at a table and I tab to a new cell, for some reason, it changes the text direction from right to left.

I never had any performance concerns. Currently, there are two of us who are using this solution, and we are developers. Ultimately, there will probably be ten of us. The other members are going to be the members of the ERP implementation team. They are subject matter experts in each department.

I and another developer are just moving all our stuff from Azure DevOps. He has never used it, so I'm kind of teaching him. We're configuring it how we want. Ultimately, I'd like the whole company to use it, but the big problem is the licensing.

I have interacted with their technical support. I would rate them a seven out of ten.

We were using Azure DevOps, which is Microsoft. It is totally free because we use Office 365 and their development tools. We used Azure DevOps for a while, but it kind of sucks when it comes to test cases, so we ended up moving over to Jira.

The biggest thing was that their boards are really bad. As compared to Jira's backlog and sprints, what Microsoft has got in Azure is just not very good. 

We also wanted to make a task of type Test, which it supports, but the problem is you can never delete it. You also can't have a hierarchy of two tasks that are of the same type, so I couldn't have two issues that were both a user story and put them in a hierarchy. It will let you do it, but it gives you a warning, and then it doesn't show up at certain places. 

We also wanted to put our artifacts somewhere. Azure DevOps doesn't support artifacts. We are on the Microsoft ERP system, and we can't upload an executable because it is not a supported artifact type. On the Microsoft ERP system, when we write extensions, it makes executables that are .app files. Normally, when we compile a new application, we store the compiled version in some kind of artifact repository. Microsoft has a feature called artifacts, but it only supports specific things. It doesn't support .app files, even though it is a Microsoft product. So, we were not able to manage the artifacts. We can't do that in Jira either, so we'll probably end up using Nexus, but the fact that Microsoft has artifacts and they don't work was just really annoying.

For me, it was relatively straightforward because I implemented it at my last company. For a new user, it is pretty complicated. It involves setting up workflows screens and issues screens, and there are so many different schemes that are interrelated.

If you're happy with everything that comes out of the box and their standard workflows and project types, you can get it up and running really quick, but if you've got specific needs, you will spend a lot of time learning about all the configurations. I probably spent a total of eight hours this time, but I have spent hundreds of hours on it at my last job.

The investment is $10 a month now. If we're paying $10 per agent per month and even have more than three agents, it is easily worth it. It is worth its weight in gold in being able to link everything together and have everything in one place.

Right now, there are only two of us who are both agents on the help desk and developers. We might be on the free version because we're less than three agents or users. I'm looking at Zephyr tests, which have a $10 a month flat rate, so right now, it is $10 a month.

There are lots of add-ons. They do a free version, a standard version, and a premium version. In the last company, we started on $50 a month. By the time I left, we were paying $4,500 a month. That was mainly because we had 100 users on Confluence. I bought an add-on for Jira software for which we had 10 users, and that was $5 per user per month. It was costing me $500 a month, whereas it should only be $50 a month. I don't know if licensing fee has changed.

I'd like our whole company to use it, but the big problem is the licensing because the Confluence side is what is really useful, but if I add 30 users to Confluence and then buy an extension for Jira software, I've got to pay for 30 licenses, even though I've only got two users in Jira software. It is the one big disadvantage of cloud software. You always have to pay for the number of seats regardless of which product you are on. This will probably severely limit how many people would use it because I'm not going to start paying $10 per user per month for a Jira software add-on when there are only two people using it.

It is free to try, so make sure you try it. The single biggest thing to look at is the licensing cost, especially if you plan to use something like Confluence, which is something you would probably want to roll out throughout the company because it is just a Wiki. If I've got two software developers and I put an add-on, having to pay 100 licenses for that is just crazy. 

I would rate Jira Service Desk an eight out of ten.