Jira Reviews

Jira is used for all the project management, on all the stages of project management. So then we create a Kanban board and move on to creating the stories.

We create the story points, break down the requirements, and then create the Sprint accordingly. Based on that, we can manage in Jira how many user stories we will pick in what Sprint. And based on the dependencies of the user stories, this is the flexibility that Jira provides. Then we have also got various, you know, sub-tasks, which we have to complete to accomplish the DoD (Definition of Done). We can mark the Sprint as complete when these particular tasks are completed. So that gives very good monitoring of the project where the project is

going on.

When it comes to the testing part, so testing is end-to-end on Jira. We can take the user stories based on the acceptance criteria. The test cases are created in Jira, and the business analyst team reviews those test cases. Based on their feedback, the test cases are updated. Those test cases are being executed. So there is clear tracking of the test execution, and all the test cases are also linked with the user storage. We have end-to-end tracking of what test case is executed for what user story. So that is the best part of Jira.

The monitoring, flexibility and tracking are really good in Jira.

When we use the plugin in Jira so, there are two different systems which we are working on, Jira and the X-ray plugin. The X-ray plugin should be incorporated into Jira because we have to fetch two reports. One report is faxed through Jira, and one can be faxed through X-ray. So there needs to be clarity about which the Jira team should reflect.

I have been using Jira for eight years. 

Jira is a stable product. I have seen the growth in the solution’s stability for the last eight years. The current version is quite stable and is a robust system.

Overall, the solution is scalable. Jira is quite easy to scale. If we have five projects working on Jira and we have about five more projects to be incorporated, it's easy to install Jira for those five projects as well. Presently, twenty five thousand users are using Jira. 

We have been using this for the last eight years and we are quite accustomed to that. We don’t need much support from Jira or Atlassian. Yes, but we have got an enterprise version of that, and their support is quite quick.

Positive

I was using HPE Quality Management Tool.

The initial setup of Jira is very easy. I have been an administrator, so I would say that because used to it. But in comparison to other systems, yeah, it’s quite easy and user-friendly. The deployment takes two to three days of time. Forty people are required for the maintenance of the solution.

I implemented it myself as an administrator of Jira.

Compared to the value Jira provides, it’s not that expensive. It has an yearly licensing cost.

Use all the reports which are generated. You have to make a system for the process. Here is a small example during a subtask. The time input via the source is not mandatory. But you have to make it mandatory either from the back end.

You’ll not be able to fetch the reports on the performance, the health of the project, capacity management, or IT management if the data is not input properly. So this is something which people most people don’t take care of as a Jira planning. But when you plan a project, you have to plan these things.

I rate the overall solution a seven out of ten.

We use it for project tracking. We do software development. We implement software development lifecycle, and we use Bitbucket for CI/CD pipelines.

We have a lot of vendors operating on multiple projects, so in terms of operations, we need to maintain the backlogs of different projects. The sprint approach for roadmaps is cool in Jira, but we are looking at whether the same option is available in Azure DevOps because one of our clients is looking into using Azure DevOps.

Jira has a good reporting system. It also has an API, so we can do all sorts of reporting. 

There are a lot of things. A lot of features, such as time tracking, are only available through the marketplace. If multiple users are working on a user story, we aren't able to pull out the reports. So, there are many things that they aren't offering. They are available only through the marketplace. That's not good for a product.

I've been using this solution for five years.

It's stable. The stability on the cloud is 99%, but we have deployed it on a virtual machine. 

Both cloud and on-prem deployments are scalable. I'd rate it an eight out of ten in terms of scalability. 

Our clients are small and medium enterprises.

I'd rate it a nine out of ten.

Positive

The setup on the cloud is easy. I'd rate it a nine out of ten in terms of the ease of setup. The on-prem setup requires some work. I'd rate the on-prem setup a five out of ten in terms of the ease of setup.

We have four people who are working on Jira maintenance.

It's not very cheap. It's also not very costly. I'd rate it a five out of ten in terms of pricing.

I'd recommend it to others. Overall, I'd rate it an eight out of ten.

I use Jira for project management. I track all my projects through Jira, including the resources, the time, the deadlines, or the roadmap. For me, it's the tool to check the status of the project. If we have time to get more people on the team, we can use it to show the up-skilling and the availability of the team.

They offer 24/7 support.

It's easy to set up.

There's lots of documentation to help you learn about the solution and troubleshoot issues.

The stability has been great.

A company can scale Jira if it needs to. 

It includes by default all the necessary tools for a project manager to work and make their work more efficient.

The reporting tool and the approval tool need work. The basic reporting tool includes only a few basic reports. If you need an advanced report you need to download a specific plugin, install it, and customize your reports on it. Sometimes you need to know SQL, let's say, in order to get the reports. It's not user-friendly.

With the approval tool, it's complicated in order to create the flow in Jira in order to achieve the approval process among different people. That needs to be simplified.

I've been using Jira for almost now seven years. I have used Jira from 2015 until now.

It's a very stable solution; we've had no problems at all with that. There are no bugs or glitches. It doesn't crash. It's reliable. 

The product is quite scalable. If you want to expand it, you can. 

We have hundreds of people on the solution in our company currently.

I've used customer support in the past and have found them to be helpful and responsive. 

Positive

The initial setup is not complex. From what I understand, it's an easy setup and it's straightforward. They have a lot of user manuals as well, and they have also 24/7 support across different countries if you need help at any time.

While there is a cost associated with the solution, and licensing needed, it's not an aspect I deal with directly. 

I'm not sure which version I am currently using. the admin team handles the versions and updates. 

I'd advise new users to read the user manual first, before jumping in. They are really helpful and informative. 

I would rate the solution at a nine out of ten. It is one of the best tools that I have used. It's helped me a lot in my daily job. For me, it's the best tool in order to track teams and projects. 

We use Jira for project management.

Our team really needed something to help us track the progress that is made against our system-level requirements, and this solution helps us in that regard.

The most valuable feature is Jira Align, which is a plugin that helps you to understand the progress that is made against each epic. I have had limited exposure to it but by using Align, we can also see the progress concerning Initiatives, including progress made against the requirements.

In general, Jira Align is very useful for management. It allows them to see the big picture and what is really happening from a team-execution point of view. Being able to see progress against their Initiatives is a nice feature.

The UI is good, and it helps us to see what needs to be done to complete our sprints.

Nowadays, many organizations are moving toward the Objectives and Key Results (OKR) framework, and this is something that Jira should be able to accommodate. Jira should understand that at the leadership level in an organization, such as the C-level or even below that, they don't like to have an epic creator. Rather, they are interested in observing all of the corporate objectives that are being turned out by the team.

OKR is a very important feature for them to add, and it's a big investment. There are separate tools that are trying to support and enable people to use this framework. If Jira could do that, it would be great because we don't want to integrate multiple tools. For example, we don't want to use one for OKR and another one for Agile backlog items. If we can have support for everything using one tool, it would be helpful. That said, it would require a big investment to implement.

The biggest drawback that Jira has is that they don't have a separate chart to show metrics for lead time, cycle time, and throughput. We use the control chart as a workaround but it's not giving us the correct metrics. The metrics are skewed because the chart shows us some items that are still in an open state. This is something that needs to be fixed. By comparison, Rally Software has a feature that enables people to understand the lead time, cycle time, and throughput as separate metrics in different charts. Having Jira implement that capability would be helpful.

We are unable to enter an explicit agreement below the kanban board, which is something that we would like to be able to do.

I have more than five years of experience with Jira.

Stability-wise, Jira is good.

Jira has no problem with scalability. It's far better if you compare it to Rally.

I also use Rally Software. Some times are more on Rally, whereas other things are more on Jira.

Rally software has some better charting features, whereas Jira is more scalable.

Between these two products, it's very difficult to say which I would recommend. Rally has some good features that are not available in Jira. For example, in Jira, we can't put an explicit agreement below the kanban board. This is something that we can do in Rally. Rally Software, on the other hand, does not have the feature that allows us to understand the progress made at the feature level or the initiative level. This is something that Jira gives us with the Align plugin.

I would lean toward Jira as the market leader. If they improved some features, such as the metrics available on the charts and support for OKR, I would prefer and recommend it over Rally and other products.

The pricing for Jira is reasonable, although I think they can bring it down because the plugins cost extra. Jira Align, for example, is available at an additional charge.

Jira should understand that there are now competitors in the market, and they should lower their prices to expand the user base. As sales volumes increase, the price should naturally be brought down. In this case, people are more likely to retain their licenses instead of switching to a more cost-effective solution.

I would rate this solution an eight out of ten.

We use Jira to manage agile development from beginning to end. First of all, we lay out a backlog of everything that needs to be done. Within the backlog, We define a sprint of three to four weeks and prioritize in Jira. The backlog is stored and the sprints are defined in Jira.

The tasks or stories fall under the umbrella label "issues." The issues are created and assigned to developers, and the testing is tracked in Jira. After one is done, it moves into the QA stage. We track that all the way until we get to what is called "non-performance testing," which is part of production. We use Jira to track the status throughout, and we have daily stand-up meetings where all the developers get together to talk about their blockers, interdependencies, the net, etc. All of this is captured in Jira.

Our client is a bank, and we use a cloud version of Jira. We are the supplier, so we're onboarded and get a login for whatever they're using. Right now it's a cloud version that we are signed onto. They use a hybrid cloud because they have their own cloud because some of their systems are private, and some are in the public cloud. 

The bank works with a few cloud providers. They are using Google for this project. We are heavy into developing microservices, which use JKE, Google layer, Google Cloud Platform, Google Communities Engine, and all the other Google components for microservices development. Most of their stuff is deployed on Google, but they are also affiliated with a bigger bank that uses Azure, so some of their systems are deployed on Azure.

In terms of product management, Jira increases productivity and visibility into the product. Those are the top benefits this tool provides to the team. Also, it's accessible to the executives and whoever wants to sign on to Jira to see what's going on. 

There are different levels at which they can see the project. It depends on what they want. Somebody can, for example, create a report, but some of the reporting capabilities are not quite there. However, Jira can export all the data to a spreadsheet. Once it's in a spreadsheet, the sky's the limit.

Jira has a dashboard called Active Sprint. The board has a button on it for every developer, and when you click on it, you can see every task assigned to them along with the status. It's great to have visibility at that level. Every developer and test is there. 

Reporting is something Jira could work on. The reporting capabilities should have the same flexibility we see in Excel, including the ability to manipulate data and create graphs. They need to have that, so we don't need to export to a spreadsheet.

Jira should add some features from another Atlassian product called Confluence, which we use to track all the documents we need for development and testing. There should be better integration between Confluence and Jira. I like to use Confluence to do my reporting, and I should be able to go into Confluence and launch reporting at the source. 

Jira acts as a data source, and Confluence is where the dashboards are. It would be easy for Atlassian to develop all the dashboarding capabilities for executives so they don't need to log into Jira. There's too much there. It would be better if executives could log into Confluence, which is a document-based tool.

We've been using Jira for nearly three years, but I've only been directly using and trying to generate reports from it for probably two years. Before that, I had my project manager do everything with Jira, but lately I've been working with it directly. I might sign on and looking at things because I want to understand what's happening with the project. There are a few things that are not right with Jira though.

Jira's stability is pretty good. I haven't had any problems. 

We've never had an issue scaling up Jira for big teams. It's not a problem for the banks I work with or our in-house development.

I give Atlassian support eight on 10. 

Positive

I worked at IBM for many years, and we used an IBM product called CMVC. The difference is night and day. Jira is much better. 

Infrastructure is all set up for us, and we go back to the bank's infrastructure team if there's a problem.

I rate Jira eight out of 10. It boosts productivity tremendously by eliminating the chaos between development and QA. Jira manages the entire pipeline from development to production. If you're thinking about implementing Jira, you should go for it. It will make your life better by streamlining the tedious daily work of project management.

I am using Jira for some programming-driven planning and PI planning system, but I have just started using it for that. I am primarily using it for some projects.

I'm serving as an enterprise agile coach, so I work with a team to help them use Jira. I'm not really sure what the exact data subjects are, but I mostly look at what the team is doing and if they have updated, then they let me know. I'm not using Jira for my own instances, but for my team's. I'm helping the scrum masters and the product owners.

The solution is deployed on cloud.

In terms of scrum teams, I find that usually, the product backlog depends on charts and especially reports like Sprint Reports. I find the reports to be very useful. With regard to SAFe Agile, I was looking at having a proper program board. So far, I have tried using the portfolio feature. Something that I have been looking to understand or learn more about is how to integrate Scaled Agile and their work types into the Jira.

I'm still exploring the solution. I think the knowledge is a challenge because most people are used to Jira for teams, but not Scaled Agile. I think that is an issue with awareness. We are looking for some YouTube videos and help pages on finding that. Maybe there are features, but sometimes we aren't aware of them. We are still in the exploration stage.

I would love to see transparency in terms of how the program is displayed when you are working in multiple teams, especially how the dependencies could be tracked. The most important thing at the moment is that it is easy to do.

Something I would like to see improved is the traceability feature. When you have a user story, if you can see all the test cases, it would be an improvement if you could see any design documents or any change management. If you can see the traceability nicely, that is also something that we are looking for. Today we can link and do things like that, but sometimes the solution has a bit of a challenge with attaching test cases, so I think we have to use some plugin. Traceability with the test cases could be improved.

I have worked with this solution for five years.

The solution is stable.

I'm not able to comment on the scalability because I work with different types of teams. Some teams are really big, and they haven't said that they've faced any challenges. I haven't specifically asked, so I'm not very able to comment on that because I don't know for sure.

I'm working with a couple of teams made up of 20-30 users or 100-150 users, and maybe more for certain accounts.

I haven't had a lot of experience with technical support, but for the questions that I have raised, I received a pretty quick response, so I'm happy with that.

Setup wasn't that big of a challenge.

Implementation was done by Jira administrators, which was good.

The license is yearly. It is a large, long-running program.

Some of my teams have been using Version 1 and Rally. Because of that, I have been exposed to those tools for some extent.

My experience is much more with Jira. That's why I tend to go for Jira, but we haven't used many other solutions. Based on teams and what the people are saying, they find Jira to be more user-friendly. For Scaled Agile, I have also heard that they have found certain features in Rally more useful. But I don't know, I haven't used Rally to that extent.

I would rate this solution 7 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 Jira in my company as a project management and software development tool. We use Jira in our company to document all of our requirements and releases in relation to project management and manage the agile lifecycle management of our products.

The most valuable feature of the solution is that it is easy to use and allows users to use agile methodology. Jira also offers a lot of plug-ins, which are helpful.

I would love to have more free plug-ins in the solution since most of its present plug-ins are great. I want Jira to have more plug-ins, which will allow for more free plug-ins that help with the area of reporting.

I have been using Jira for four to five years.

It is a stable solution as it is a cloud-based product.

It is a scalable solution, but it comes with an extra cost.

More than 100 employees in our company use the solution.

My company has not faced any problems or issues with the use of the solution. That tool's use can be easily extended.

As everybody in the organization has a role in the use of the product, employees ranging from managers to developers use it.

My company has not faced issues with the use of the solution. It is very easy to reach out to the technical support team of the product if our company faces any issues with the product. My company just needs to schedule a call with the technical support team of the product, and they readily help us. The solution's technical support is good.

I have worked with some other tools in the past. My company chose Jira since it was easy to use, scalable, and pretty straightforward.

The product's initial setup phase was straightforward.

The product's deployment phase was straightforward, as one just needs an account to log in. As not many technicalities are involved in the product's deployment process, it is useful for project lifecycle management.

The solution is deployed on the cloud. Jira also allows users to opt for an on-premises deployment model.

There is a need to make yearly payments towards the licensing costs attached to the solution. The product offers flexibility in pricing since it depends on the memory bits you have used.

It is a perfect tool for those who want to manage the projects in their organization.

The benefit I have seen from using Jira is that it streamlines the development process. In general, the solution provides visibility and streamlines processes.

I rate the overall tool an eight out of ten.