Jira Reviews

We primarily use the solution for software management. 

I really like the linking and user stories, and the formatting on the solution. The formatting options and linking the user stories have been great. 

You can export the whole backlog if you want to - including your roadmap.

The initial setup is easier than the TFS.

The UX and useability os good, especially if you compare it to a solution such as TFS.

You can use it right away without too much of a tutorial. 

The solution is stable. 

The scalability is good.

I would suggest Jira makes the format compatible with Microsoft Word. Currently, when you copy and paste something from Jira, such as tables, it won't be the same when you copy it into a Word file. There are formatting issues. 

If you have 70 or 100 stories, it doesn't work to copy and paste or export each one individually. There needs to be better configuration at a categorization level. 

There needs to be a way to export a user story. 

By default, Jira is epic and story only. It would be ideal if there was a different categorization between the two. It would be nice if there was a third story option. 

There should be a plugin for test cases. 

If the solution doesn't have third-party plugins for some features, they should add it into the main offering to make it more complete. 

I don't have a lot of experience. I only have about four months of experience or something like that. It's not a huge amount of experience, however, I got familiar with the basic features of Jira over that time. The first two months might have been on a trial version.

The solution is stable most of the time. Only rarely are there some points where it's not stable. For example, when you view some issues, sometimes it gives an error. Then, after that, if you refresh or you open it at another time, it may work again.

The solution can scale. If a company wants to expand it, it can do so.

We have more than ten people on the solution. 

If you need to find answers, the community FAQs are pretty good. I've found issues in there in the past that have helped me troubleshoot. So far, I'm pretty satisfied with that aspect of support.

The initial setup is straightforward and simple. It's not difficult or complex. 

I don't deal with pricing, billing, or licensing. I can't speak to the exact cost of the solution. 

We likely pay a licensing fee as we have more than ten people using the solution, however, I can't say what the exact cost is. 

I have been researching the difference between Jira and TFS, to decide what is better for our team to use. I'm very familiar with Jira. However, some of my team members have experience with TFS. I'm trying to decide which management tool we will use in an upcoming project.

I have found that, with TFS, a lot of the features are built-in, however, with Jira, you are required to add in plugins. 

I'm a customer and an end-user.

I would rate the solution at an eight out of ten. For the most part, we have been satisfied with its capabilities. 

I would recommend the solution, however, I would warn that likely a company will also need to add many plugins in order to get the solution to do what they need it to.

I primarily use the solution for use cases and make sure that our tasks and priorities are getting done.

I like that we can actually categorize the stuff from high priority to a lower priority. You can make categories and you can focus on the right items that need to be worked on. 

The initial setup isn't too complicated. 

The solution is stable. 

The scalability is good. 

It is not intuitive. It was hard for me to understand how to use it right away. It would be ideal if they could make the solution more user-friendly so that it is easier to pick up.

I haven't been using the solution for that long just yet. it's been about six months or so.

There are no bugs or glitches. It doesn't crash or freeze. it's reliable and the performance is good. 

The solution can scale well. it's pretty straightforward if you need to do so.

We have product owners, project managers, and scrum masters on the solution. I would say that we have a thousand people using it, however, I'm not saying that for sure, as the bank has 46,000 employees and I'm just a part of a small team. I'm estimating that I would expect over a thousand people to use it.

I have never used technical support. I've been able to manage everything and figure stuff out with the stuff I have here. Everything is available to me.

I did use a different solution, however, I switched when I switched roles at the company.

For the most part, the solution was set up for us. My understanding is that it was pretty simple I assisted a bit, and I found that the navigation piece was not enjoyable to implement. 

I'm not sure which version of the solution we're using currently. 

I'm a customer and an end-user.

I'd advise users considering the solution to make sure that they have a little time to review it and understand the tool and make sure they actually find that it is a good solution to meet their needs and that it's what they're looking for. From Agile delivery teams that are here to deliver their MVPs and stuff like that, I think it's great to keep track of all their backlogs and stuff like that. It is also great for someone from a use case perspective as they break it down well.

I'd rate the solution at an eight out of ten. Of course, I'm still learning it. That said, it's great for keeping track of all the items and the stuff that needs to be done and for the use cases that have been closed, to make sure that we get the proper sign-off and understand the line of business. 

We are using the recent version.

We use it for story and sprint planning, as well as for reporting. 

The solution benefits our organization with its agility, planning and visibility in respect of large teams spanning different geo locations.

The tool is well known and popular to use. 

The sprint planning is pretty good, as are the reporting piece, retrospective reporting and the planning board. 

It is a great tool from the planning perspective, such as that of capacity and sprint planning. 

As the solution is highly configurable, it has very poor governance. There is nothing which comes out of Jira to go into the product. It is free for all and anyone can create with it. This means that the responsibility lies with the user community to create some form of governance. 

Moreover, the solution is geared to small teams. It lacks scalability. 

The tool is not good at the enterprise level. This means that, depending on how the person installed the software, the issue of performance may increase commensurate with the number of projects. While plugin for x-ray exists, it is not that mature in test management. Although it's a good tool for many of the smaller clients, once a person goes deeper into it, it's not there, even though it will get the work done. 

It is a less desirable solution in controlled environments, such as science, banking and finance, in which there is a need for certain compliance supports.

The solution is not that great for audit histories. It's a great tool when much integration is involved. With cold products, things can always be achieved through other means. 

When the teams collaborate, they need multiple metrics to be tracked. With this comes the issue of direct impacts, such as the appearance of one's UI and its usability aspects. The screens have changed greatly in appearance over the last ten years. This is an issue which every software dealt with in line with the growth of usage and complexity. 

I have been using Jira for nearly ten years. 

The solution is stable. 

The solution is good for small teams. It lacks scalability. It does not work well when it must be used across multiple domains and multiple teams which need to collaborate. 

The Atlassian strategy is that the solution be open to all to encourage collaboration. But, this raises the issue of how to control the data input and the tool and all that it comprises in respect of the reporting that is generated. This means that poor data quality in the geo projects will equate with poor reporting on it. 

As such, supplementation by the teams or organizations using it is required. They must come up with their own rules of governance about who can do what. 

The product is not being extensively used at the moment. It is a niche product. I have not seen usage behind it. It involves ID users for certain teams. 

We do not have plans to increase usage. This will depend on the feedback we receive. 

I have not made use of technical support. 

We did not switch to Jira. It is simply one of the products that we also use in addition to an in-house micro focus ALM. 

While I was not involved in the initial setup, my understanding is that it is simple. Atlassian puts out many different products and I cannot say for certain how I would have handled ones which are on-premises, compared to those which are cloud-based or server products. 

I am not in a position to comment on the licensing. 

We make use of the solution on Jira Cloud. 

While I cannot say with certainty, I would estimate the number of users in our organization at a thousand-plus. 

This figure contemplates different departments, such as that involving support. 

My advice is that someone in a large enterprise first give consideration to the issue of governance before implementing the solution. For a small team it is ready to use straight out of the box. One need just try and stay with the default workflows. There is no need to overengineer the product. 

The product is good, stable and very cost-effective for small teams. These are some of its advantages. 

I rate Jira as a seven out of ten. 

I believe we are using the latest on-premises version. 

Confluence, not Jira, is the most convenient feature with Atlassian. We use the product for knowledge management, the use of creating or documenting knowledge into a knowledge base.

I would like to have a future-proof idea of the cost and the roadmap for my class. This is in light of the fact that they are switching things up, promoting the cloud service and mixing different support levels.

The CMDB and knowledge platforms that are in the background of the ticketing tool should also be addressed. 

I have been using Jira for five years. 

When it comes to the question of stability, this depends wholly on the amount of resources provided to the virtual servers, since we make on-premises use. 

We have internal Atlassian experts, so it is tough for me to comment on the technical support.

The price of the solution could be lower.

We are currently in the initial stages of contemplating a switch from Jira. 

My advice is to work closely with Atlassian to make sure that all the designs are future-proof.

It is tough for me to Rate the solution. There are features needing improvement, but also many good things about Atlassian. As such, I rate Jira as a seven out of ten.

We use Jira for task tracking, sprint planning, and backlog.

The dashboards are useful. You have visibility across projects and various dashboards.

The status of the different activities is also helpful 

In general, it is not user-friendly. 

For a non-technical person to use, Jira is not intuitive. If you are a developer it's fine, but we are trying to get other technical people in to look at tasks or to update a task, move it from one sprint to another sprint and it takes more effort than I would like.

I would just like to see it easier to use, and I would like the workflows to be less complex to do what we need them to do.

My experience with Jira is limited, but the organization has been using Jira for three years.

We are using the latest version.

Jira is stable. to my knowledge, we have not had any issues with bugs or glitches.

The scalability can be complex if you are using workflows.

We have approximately 20 developers and some managers in our organization who use Jira. 

I have not yet used Jira technical support.

Previously, we did not use another solution. We started with Jira.

Along with Jira, we use Microsoft Azure DevOps.

The initial setup is fairly straightforward. 

It was fairly simple for us.

I would recommend getting sound knowledge first. It is difficult to go back later to fix things, so try to build it right the first time.

For the functionality that exists, I think that it's good.

I would rate Jira an eight out of ten.

We are using it for service management, change management, project management, and tracking the changes.

It is user-friendly, and you can manage your project according to the methodology you want. It is also easy to configure.

The dashboard reports can be improved. Its dashboard reports are good, but you cannot have complex reports. They are currently very basic. For instance, we can only choose two columns for a dashboard, so it is not friendly enough.

So far, I've only used the project management parts. We are examining resource planning and sample plugins for the product. From my point of view, resource planning is a little bit hard to link with project management. Sample plugins are another part of the system, and we need to link it with project management in the BigPicture screen, which is a little bit hard. It would be valuable for us if we can do resource planning in BigPicture as well. Currently, it is another plugin, and you can only plan based on the people and not projects, and you cannot link it, as far as I know.

My company has been using it since the beginning of this year. It has been around six months. I have been using it for three weeks.

It is stable, and everyone generally looks satisfied.

We are trying to settle the project management part and widen it to all countries in our company. There will be many users.

We are working with a consulting company. Technically, we are okay because all of us are using it now, and there is no problem. We just need to see more details of some of the modules of Jira.

For its implementation and deployment, they have been working for one year.

Jira is a big platform, and you can use staff management, project management, and other fields that all companies want to use. If you use Jira, you will see the whole IT governance in one system.

With this solution, we can see the full picture in detail, but it can be improved. Resource planning is not easy for our project base.

I would rate Jira a seven out of 10. It will be an eight in the future. I need more time to work on Jira.

We are basically using it to support the UAT tasks. We are also using it for IT support task handling and working together as a team in our company. 

At my workplace, we are using its most updated version.

I'm working in the IT department, and the ticketing system is the most important service for us. We are also using some automation add-ons. It a very good product for handling tickets and tasks and managing processes. It is also very useful and easy to use.

It would be very practical if you can more freely reach the information that is already inside the system. Currently, we have to buy add-ons for it. There is a lot of information in the Jira system that you can handle only through add-ons. You cannot reach such information on your own. If you want to use this information, which is already in the system, you have to buy some add-on to use. For example, information about how much time an assignee is spending on a ticket is there in the system, but you cannot access it without an add-on. JQL is a very good way to reach the data inside Jira. If we can reach more objects, even through JQL, it would be great.

There are a few small functions that we are missing in it. For example, you cannot rate a ticket. If you would like to use a rating for a ticket, you cannot give stars or something like that.

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

We rarely come across any issues. Sometimes, it slows down a little bit, and then usually, we just have to rebuild the index. That's all. It needs lots of resources and CPU memory. If the resources are okay, we don't feel any problem with it.

It is probably easier to scale on the cloud. The on-premise is not so scalable, but if you can define the resources, it works well.

In terms of the number of users, we have around 750 users.

We do not directly contact Atlassian. We have a support company that helps us with any situation.

It is simple to initiate or install the product. It is easy and simple, but if you make some designs inside and build some projects with some automatization, it can be more complex.

We first tried to build the system inside the Docker environment, but it was not a success. So, we switched to the normal installation mode. Installing the product and making it work took just a few days. It included building servers and a database.

We do it on our own, but we have some strong support. We have outside support in case of any problem with it.

In terms of maintenance, you have to do the updates. You have to upgrade the system and handle the add-ons versions. If you build the inside environment in the Jira, you always have to fast forward to the project.

We have two teams to handle the maintenance. For standard maintenance, where you are upgrading the versions, we have an IT professional team for it. For the inside environment of the Jira projects and automation functions, we have a service management team.

If you are using just Jira, it is cheap, but if you start to use it and you feel you need some more services or more functions, then you have to buy add-ons, which can make it expensive.

I would recommend this solution. I would rate Jira an eight out of 10. It is definitely not perfect, but it is almost perfect.

We have been using Jira for schedule management as well as for making updates to our projects. I mention this in my capacity as a project manager. I most recently used the solution this year and did so for scheduled management of our varied tasks and projects. JIRA is actually used to put together an entire portfolio for each one of the teams, meaning for everybody. The solution listed each of our projects individually, with us needing to provide daily and regular updates. 

A most valuable feature involves the ability to customize the entries and to update them quickly. Unlike what was previously available, the solution allows us to create specific codes and symbols for the individual teams. The new version allows one to customize and to use demarcators. There is a code that can be entered in Align upon completion of a project or task and this apprises the project manager that it is time for its removal. 

Something I do not like about the new version is that there is a need to browse all the way back to the beginning, should a person click on a task that is specifically for his group and wish to go back and look at the other portfolios or people. However, I cannot state definitively if this situation owes itself to the way our team put the site together or to something administrative. When clicking the back button it would take the person to the wrong page, not to the one he desires. One would actually have no choice but to browse back to the portfolio and to find his group again and open it. Again, it is not clear to me if this problem lies with Jira or with the way our team laid out the site. 

I feel Jira is stable. The only hiccup which comes to mind is the one I mentioned, although it is not clear to me if this owed itself to the network we were using or to limitations of the application. Except for this, everything about the solution is stable. The only time a person can not look at the information is when the administrator announces his intention to remove it. 

The scalability is pretty good and we started on this process from the moment we started utilizing the solution. While we had only three teams and three sections, between December and January 15th the developers came together and expanded from three to 76 different tasks across the different teams. By February there were over 300 teams. Expansion is easy and did not just encompass our teams but also provided links to others that were outside of our main team set so that there were reference points available.

I would say the tech support is pretty good. I got back a couple of answers in response to an email I sent out. 

It was quite easy for me to set up my own pages. I had a field day with creating my own test pages and was able to play around with them and simply test out the different settings. Pulling in new documentation was very easy. The same holds true with pulling in attachments and it was, consequently, easy to set up. As well, I was able to set up certain sub-pages for our team for going in and checking JIRA.

There were initially eight people involved in the maintenance of the solution and deployment of updates. They had the people to whom they answered. We are talking about a large-scale effort. Without taking into account the Jira support line, I would say there were around 12 people managing and administering this version. For our specific team, there were around three. They were the actual decision makers. 

I am not in a position to comment on licensing costs. 

Our team does not use the solution exclusively. There are multiple ones which do, although I cannot state how many teams are doing so. I do know that the entire section of our agency is doing so and this accounts for a lot of people, well over a hundred. 

The solution is pretty good and is geared towards those with multiple teams who are using it for the same purposes as us. We use it for providing daily and scrub updates, for which it is really good, as it allows one to track every entry and see when it's entered, timestamp and all. So, if a person has a lot of mission-critical or time-sensitive activities, JIRA is pretty good for tracking and helping to keep everything organized.

While I am still biased towards services at the moment, I rate Jira as an eight out of ten, at it is really good and very functional. 

We use Jira to manage all our software development projects and our engineering projects. Our main use of the solution is for the workflows on our different types of projects. It's mainly used by our engineering groups, they have the proper workflows and all of the stats. As a director, I work more at the business level, tracking tasks similar to the new planner that's in Microsoft which some people are switching to. We also use it in the backend of the projects. For project managers and directors, it's more about a to-do list thing that's shared. I'm a company director and we are customers of Jira. 

The online collaborative nature of the solution has been helpful. Previously, coordination was done in Microsoft Project and Excel spreadsheets. The level of collaboration and the accessibility of the information which Jira offers has greatly improved things and we've also been able to build out and fine tune the workflows and the integration into the different tool sets. We're definitely going to keep using Jira.

I think the customization and tailoring of the workflows have proven to be very useful. And then there's the collaboration of the tool itself which has a lot of nice features. 

One of the issues is tracking the hours that people spend on each task. I know the solution has some built-in features but it doesn't quite meet our needs. We tried a couple of expansions unsuccessfully. Being able to track the effort on each of the tasks is important for us and we'd also like to be able to compare that with what's been budgeted. It would be useful. We've recently moved to Teams and some of the integration with Teams doesn't seem to work, whether it's not supported or not there, the ability to integrate that would be something we'd like to see. 

We've been using this solution for over five years. 

We haven't had any issues with stability. 

We're a fairly small organization. We've scaled up to around 500 users and we haven't had any issues with that. It's mainly used by our engineering group, and our active users use it all the time, on a daily basis. We'll increase as we organically grow. 

I can't recall the initial setup but it took us a while to figure out exactly how to use it. We deployed using our own staff. 

I don't know what the licensing costs are but we find them affordable. It's never been a major issue.

This is a powerful tool and allows a lot of collaboration, it's worth spending some time figuring out how your workflows will be, that's where the real value is.

I rate this solution an eight 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.