Microsoft Azure DevOps Reviews

We use it for requirements, development work, and testing. 

We're doing an implementation at the moment with the client. So, it is the latest version that would've been uploaded.

It is a cloud-based system. So, it is stable and scalable.

Azure DevOps is set up more for development and less for testing. If it is set up correctly, everyone can use it better, but it was set up from a development point of view, which means it is lacking in what I need from a testing perspective. Just like any other tool, it depends on how it is configured. I am not happy with the way it is set up. It is configured more from a development side, and it doesn't necessarily cater to all the other areas that probably need to use it, such as testing data, etc.

I have been using this solution for about 15 months.

Its stability and performance are okay. It is on the cloud. As long as you have got access to it, it is stable.

It is a cloud-based system. So, you can add more bandwidth. It is scalable on the cloud.

We have about a hundred users who are using this solution. It is used on a daily basis.

A third party deals with the technical support of it at the moment.

I wasn't around when they initially set it up, but the way it is set up, it is too complex. It is probably good for developers, but it is not good for the testing side. 

It is a third party that sets it up. I don't know about its maintenance because I'm not that close to it.

I would advise organizing and doing the right assessment for all teams that are going to use it. When it is being set up, more people within the program need to be involved in the setup, not just the developers. You need to know about the requirements for design, development, testing, integrations, and architecture. You need to solicit requirements on what each one of these teams needs from the tool before the tool is configured. When you set something up only from the development perspective, you forget that there would be a need to extract information for data testing and training. So, you need to assess who all are going to use the tool so that you set it up for maximum usage.

At this time, I'd rather not recommend it because it wasn't set up correctly. It wasn't set up with other teams involved. In a year's time, if I'm working on it again, I may have a different opinion.

I would rate it a five out of 10.

When I was working at Microsoft, I was one of the core influencers on the feature set and had deployed this solution internally across several organizations. We used it for anything from its CoreALM feature sets to inventory tracking and workflow management and operation support and finance management. There were a bunch of other scenarios. At its core, it is a database with a front end that easily makes it so that you can create new forms and stuff. Then they expose an API, which means you can do a lot of things with it beyond its core use cases.

It becomes a single source of truth for whatever operation is implemented within it. You can have your product definition in there from a requirements management standpoint and then log in bugs and defect management and RPNs and a bunch of other things. You have this single source of truth as they provide an analytics service, and then also easily tie into Power BI. It's really easy to just look at the health and overall operation of your entire business from a single source.

The extensibility of the work item forms and customizations as well as the backend API to query the data, et cetera, and manipulate the data programmatically are all very valuable aspects of the product.

The UI, the user experience, is challenging for newcomers. Once you get it, you get it, and it's not too bad. However, it takes some effort to learn how to work with the system. There's a moderate learning curve. I've used both Jira and Azure DevOps, and I would have that same feedback for both tools.

The biggest challenge has been that both Azure DevOps and Jira tend to pivot more towards software development and the industry is going more towards full end-to-end product development - hardware and software. These platforms could do a lot more to help support the mechanical, electrical, controls, robotics, and more of the hardware side of things.

I started using the solution in 2010. It's been about 12 years. 

I haven't had a problem with stability. There aren't bugs or glitches. It doesn't crash or freeze.

When you surpass a terabyte of data from a work item standpoint, certainly there are some limitations in performance as the running is querying that large data set in the backend.

I've done multiple different deployments. Sometimes, the smaller, smaller deployments have been a handful of five people, and it might be three software devs, a test engineer, a hardware engineer, and a PM. 

I've also done larger deployments where it's 8,300 people. That was a mix of hardware, software, PMs, firmware engineers, front-end, full-stack devs, mechanical engineers, electrical engineers, et cetera. 

In the deployment that was 8,300, it's actually still deployed there and growing. Another deployment I was a part of that was a medium deployment - 20 users - has since reduced more due to politics and going back to the front-end, ease of use. There are some folks that it was too high of friction to use it. You can scale it up or down to match your needs.

I don't deal with technical support in the traditional sense. I know the developers who've developed it, so I just go talk to them.

I've also used Jira.

I previously used SharePoint and Microsoft decided the direction of SharePoint to be less workflow-oriented and less list-oriented and more as a document store. As their roadmap moved away from work management, I've moved over into the TFS/Azure DevOps world.

I was a Microsoft employee. There was some natural tendency to just go with the Microsoft tool, however, it wasn't a hard, fast requirement when we just looked at the feature sets and stuff. 

I've been a developer on the backend. In terms of setting up the product, my answer would be highly complex. If I were just doing it for a core user, set of users, then I would say the setup was relatively frictionless. I would say the one point of ambiguity is for some newcomers if they don't understand the difference between CMMI templates versus Agile, versus Scrum, they'll find it complex. I've seen a lot of new users create dummy projects to then go in and see how each of those is configured from a template standpoint. Work could be done there to just reduce that level of friction.

In terms of deployment times, I've been on multiple different sides of levels of deployment. From the simple side, I've seen deployments take as little as a couple of minutes. If it's teams of five, for example, they go into the web app, they start up a new project, and boom they're in. They get all the requirements and user stories and all that stuff done. 

I've also been on the other side where it's been nine months with 22 people working full-time to configure and deploy this system across thousands and thousands of users. It just depends on the size.

It's hard to put a number on managing the plan of record. I haven't tried to calculate an ROI. It does what it's supposed to and it's more accessible than an Excel sheet.

The solution costs $5 or $10 per user, per month. It's a nominal fee.

I would actually prefer it in that they give you the first five users for free. That little bit of free users goes a long way, just from an initial trial and adoption standpoint. I would encourage them to keep doing things like that.

If you use the other services - if you use their build and compute engines and stuff like that, they charge some amount for computing and some of their extensions. These are not necessarily Microsoft's extensions. They are third-party ones and they'll charge. Depending on if the feature is core to the product, or it's an extension, it might or might not cost you something extra.

I've evaluated pretty much every ALM.

We're just a customer and an end-user.

I've used all the versions, starting back with Server 2005. Now I'm just using their online version.

In terms of advice I'd give to new users, I'd say it goes back to basic change management. Understand who your attractors and detractors are. Lay out the feature sets, ease of use, and things like that. That at least will help detractors become a neutral party as there are always going to be people that create friction within a deployment. Just have an effective change management plan. I've looked at over 12 different ALMs and they all have their pros and cons. It really just comes down to just picking one and going forward with it and learning it.

I would rate the product at an eight out of ten.

With Azure DevOps, I plan and track my project using Azure Boards, manage my code with Azure Repos, and automate build, test, and deployment processes using Azure Pipelines. This streamlines my development workflow and ensures efficient collaboration and project management.

The most valuable feature in automating our build and release processes with Azure DevOps is the scheduling capability. At the end of each sprint, we schedule automatic releases to QA and development environments, ensuring our latest code gets deployed without manual intervention. Additionally, triggering pipelines upon code upload to the main repository adds significant value to our development workflow.

Azure DevOps could be improved with more security plugins, especially for SaaS scanning and vulnerability scans.

I have been working with Azure DevOps for two years.

I would rate the stability of Azure DevOps as a ten out of ten.

I would rate the scalability of Azure DevOps as a ten out of ten. At our company, it is used daily.

Technical support from Microsoft is very helpful, especially when I need assistance with tasks like migrating work items between Azure DevOps and other platforms. I would rate the support as a ten out of ten.

Positive

The initial setup is easy. Deployment typically takes around ten minutes at most. We have set up an automated process that recreates everything, so even if there is damage to the VM or target machine, we can quickly retrieve and redeploy everything ourselves.

We require about two DevOps engineers to maintain Azure DevOps for our company, which has around 400 users in total.

I would rate the costliness of Azure DevOps at a seven out of ten.

We ensure the security of our company's source code uploaded to Azure Repos by using a SonarQube Plugin and then automate its deployment to various environments like development and QA. Once approved by QA, we deploy to the production environment, passing through our firewall for protection. This streamlined process ensures efficient and secure CI/CD pipelines with Azure DevOps.

Azure Boards has significantly improved our project tracking and adjustability. It is a powerful tool where we can easily trace work items and monitor the progress of our projects.

Azure Boards is a powerful tool for tracing work items and project progress. It simplifies uploading and versioning of project assets and tools, enabling easy refreshes or benchmarks.

Overall, I would rate Azure DevOps as a nine out of ten. I would recommend it to others.

We produce multiple different software for different markets in different countries. It's really for everything you can possibly think of, from online games to financial systems, to payment gateways, to APIs, to service desks, back-office analysis tools, admin tools, et cetera. We use it for anything and everything really.

The solution is great due to the fact that it's kind of an entire ecosystem. I'd say the work items are probably the most valuable aspect.

The stability has been great.

The solution is scalable. 

The interface is very bad. It's an aspect that really needs to be worked on. It is going to probably get the developers to start abandoning work items.

Our initial setup was quite complex. 

The presence of Microsoft in the country is limited.

I've used the solution since it came on the upgraded from Team Foundation Server - about ten years. We've used it for a very long time. 

The stability has always been really good. There aren't bugs or glitches and it doesn't crash or freeze.

We've found the scalability to be good. We have about 2,000 users on it right now. We haven't had any issues with scaling as needed. 

For us, the initial setup was extremely complex due to the multiple organizations we had on the go. We actually had to abandon our initial rollout and rethink the whole process though. 

I'm in compliance, and therefore cannot speak to what the maintenance process is like for the solution. 

We had a combination of both in-house and vendor help with the setup process. We've got enterprise agreements with Microsoft, so they always give us resources to assist with our deployments. We already had TFS deployed, so it was an upgrade, really.

I don't deal with licensing. I can't speak to how much the solution costs.

I'm just a customer and an end-user.

I'd advise new users to plan very carefully the way that they would like to set up projects. The model that you choose is extremely important and you might have to do a lot of rework if you don't get it right the first time.

I'd rate the solution an eight out of ten. It's Microsoft. It's backed by the mighty, mega Microsoft. You can't get fired for choosing the top product run by a top multinational company. The downside for us here is, in South Africa, there are only two points of presence. For the data, if it's fully hosted, we only have Capetown and Johannesburg. When it comes to back hall speeds for internet, it could be better if we had points of presence in all the major cities, however, I suppose it's too much investment for Microsoft to make.

I work for a telecommunication company that offered television via IPTV. 

IPTV is an internet protocol television, such as AT&T U-verse or Fios from Verizon.

All of the IPTV systems are proprietary, meaning that's not open to the customer, only to the infrastructure. Before Microsoft Azure DevOps, customers only use what are called set-top boxes. When you are deploying Microsoft Azure DevOps, you don't need the set-top box anymore. You only need a client that can go in, but you have to deploy it. You have to understand what the customer has and what they needed to have in place for on-premise, hybrid, or in production.

Microsoft Azure DevOps does not use the set-top boxes. You have something else that is called OTT or over the top. What that means is the deployment that you're going to do depends on the client the customer is going to use. The deployment has to be tested, and that's why we have the different deployments available, on-premise, cloud, and hybrid.

The most valuable features of Microsoft Azure DevOps are high-level protection. The protection is very important to the customers to prevent eavesdropping. eavesdropping is when a hacker tries to get into the solution. With this solution is it difficult for them to do it.

In the hybrid deployment, you can test everything. The customer was perfectly happy that developed the code, and when they put it in the hybrid Microsoft Azure DevOps and tested it as if it were in real production. That's the part that I've really enjoyed the most, is seeing how a product that was developed by the customer was tested perfectly. If something is wrong, we come back to Microsoft Azure DevOps for whatever they need to do. If they need to go deeper, they can use TFS which is part of DevOps and show it to the program manager or developer.

Microsoft Azure DevOps needs to be updated in my time. In the application that I was managing myself in the deployment and support, it was updated every six weeks. The customer had new features or new batches. Batching is an update of the software. Unfortunately, some of the DevOps or some of the people that were working on that part, do not have the final experience from what customers have. This is something that I did with several teams in Microsoft. We told the product unit manager if you want to understand what is happening from a customer standpoint you need to start from the beginning. Having customers find a problem can not be the only way to find issues to resolve them. 

Testing is very important. Microsoft Azure DevOps tests very well. However,  DevOps teams need to be aware of what they are impacting when someone updates anything on the system.

I have been using Microsoft Azure DevOps for approximately 

It's important to know what kind of DevOps you are going to have. If they're going to work with Microsoft Azure DevOps, they need to understand the solution very well. They cannot just start doing things because they wanted to try and do them.

Microsoft Azure DevOps is scalable if you have everything in place, such as the service map and processes. Before you do anything, you have to understand what the impact will be on the customer.

We had over 10 million people using this solution worldwide. I have worked in many countries, such as the Americas, Canada, and Chile. Many of our product groups were in China, India, France, and Israel.

I have used Amazon AWS previously.

When I compare when Microsoft Azure with Amazon AWS. The two of them offer the same features. You have the storage, performance, connectivity, et cetera. However, on the hybrid, Microsoft Azure DevOps is a lot better than Amazon AWS because you can emulate it perfectly. The hop counts matter, which is how many times one communication connects on its travels from one device to another.

There are three ways to deploy Microsoft Azure DevOps. To set up all three deployments is very similar but different. The on-premise deployment is where the customer owns the code. What Microsoft Azure DevOps does lets you develop your code, and when you have finished your code, you have to put it in the cloud for the hybrid. Then you can test it in an environment that is similar to production. I was in charge of making sure that everything was set up correctly.

I was involved from the beginning of the implementation. I'm a project manager myself too. I don't have certification, but I've been doing project management all my life. One important element when doing the implementation is the voice of the customer. No matter what you're configuring or setting up, if the voice of the customer is not there, but the voice of the business and the employees is, that is only two-thirds of what you have to do.

For example, I want my customers to run this application even if they are in the jungle. If they have access to WiFi, cellular signal, or hotspots, they can have access to anything that Microsoft Azure DevOps can give to them. Except they need a client, and that's the other part. You need to understand what clients the customers are going to need. The clients depend on three things. You need to know the infrastructure of the customers, their immediate needs, and the needs of their customers. We're developing something for the customer who has customers. Unfortunately is not only DevOps, it's everything. DevOps is only one part.

DevOps has one issue. There are components that are produced and supported by other teams somewhere else. Service maps are very important to develop with DevOps teams. When we develop the service map, they know what to do. However, some DevOps do not like to have service maps, because they say that they know what to do. That's what the problem is, they need to understand that they're not alone.

I have worked with integrators, vendors, resellers, consultants, and in-house teams.  

You have to be a very good project, delivery, and program manager, in order to understand how to work with vendors.

For example, you need to know how to work with people who, are going to cable a house, building, or something similar. You need to understand specifically what are the requirements that they have as a company. Additionally, you need to understand the company to know the requirements of the customers. If you are not familiar with any one of those, the deployment is going to be a total fiasco. You have to know what is going on. 

You have to know the vendor. The vendor can tell you a lot. For example, when the materials are available, if there is a problem with the supply chain, what do in this circumstance. The vendor knows about the RMS or the return of the devices. You have to know everything from the deployment, such as RMS to return back, refunds, purchase orders, and goods received.

The return on investment from Microsoft Azure DevOps depends on how many customers you have and how fast are you going to be able to have something ready for your customers.

I have a customer who wanted to start quickly on the cloud. They have about three million customers working in one area, and only when 100,000 started did they receive a return on investment. It was not immediate but in approximately a year or a year and a half, they had a return on investment with every single customer.

The reason that customers are going to the cloud is that it provides the ability to reduce the license cost. For example, when purchasing Office 365 it is bundled with Word, Excel, PowerPoint, Access, and many other applications. In the past, purchasing a license was approximately $600. Today it's only $35 or $45 per customer, per client, or per user, plus the storage. It's less expensive for companies today, to use something, such as Microsoft Azure DevOps, and provide the software to all the employees needing a license. It's better to go with the cloud than just to buy the licenses by themselves.

There are some additional costs. You pay for how much space you are using. If you don't use too much space, then the price will be very little. If you use a lot of space, you have to pay for it. Additionally, they offer readiness training. It is not included directly in what is called a statement of work when you are doing business with customers. This is when things can be a little more difficult because it can be expensive for customers if they want to change deployments from on-premises to cloud or hybrid.

The voice of the customer is very important. Develop the software based on the voice of the customer.

I rate Microsoft Azure DevOps a seven out of ten.

We use Microsoft Azure DevOps for CICD, and to organize it in order to visualize the ongoing work.

It allows you to save time while also providing a governance visualization of ongoing activities and transparency.

The most valuable feature of this solution is that it saves time.

The price could be reduced. It is expensive, especially when it comes to infrastructure.

The integration could be better. Being more technology-agnostic through ease of integration would be beneficial. Once you start working for Microsoft, you are frequently tied to Microsoft.

I have been using Microsoft Azure DevOps for the last ten years.

Microsoft Azure DevOps is a stable solution.

Microsoft Azure DevOps is scalable.

I would say the technical support is fine, but I have not had any trouble with the solution.

I have some experience using Jira.

It is very expensive in comparison to others.

As the cost structure is per user, I would recommend paying the cost structure based on the amount of data you use rather than the number of users.

I have recently researched Jira, Microsoft DevOps, TFS, and Micro Focus.

Mostly, because of the pricing, I would rate Microsoft Azure DevOps a seven out of ten.

We use Microsoft Azure DevOps for management, e.g. managing items that we need to work on, planning activities, connecting to components to get information on how long the developer is working on the items assigned, etc. We use the solution for our projects.

We have internal users from the development team, and we have the work logs that we need to work on for each customer. We match those to have control over the projects and the budget. We have a component plugged into the solution for the billables and performance delivery. What we don't have yet is optimization, and that is something that needs to be improved in Microsoft Azure DevOps, but the solution has all the activities and the budgeting functions, so the project is working good. We're making an exact component in seven days that we can use with the solution.

One of the features I found most useful in Microsoft Azure DevOps is that we can use it to plan activities. We use the dashboard to work on the tasks we have, and also use it to find out what could be better. It's also useful when you have many customers and many people working together on different projects.

In our case, we have one developer working on more than one project within the same day, week, or month, and Microsoft Azure DevOps helps give better control of his schedule, making it easier to find out if the developer still has availability to take on new work. The solution helps us see the work status and availability of team members, making work management and task management better.

The validation and quality offered by Microsoft Azure DevOps are very good. The user experience is good. The speed of the solution is also good, e.g. the pages load fast.

The optimization feature in Microsoft Azure DevOps needs improvement.

Sometimes, having control over multiple projects for a customer could be difficult. If you're a developer, you need to know if you still have time to work on more activities within the day. When you're working on one project for one customer, Microsoft Azure DevOps is great, but when your team is working on different projects for several clients, it may be too hard to handle, e.g. you really need to organize and plan the activities, so planning is another area for improvement in the solution.

Planning includes budgeting, e.g. creating a budget for each project, especially if the developer is working on multiple projects of customers. You need to have control and see to it that you are within budget, but it can be hard because you can't always see the daily, weekly, or monthly activities of the developer, particularly if the developer doesn't keep the calendar updated. We want to be able to view the complete list of activities of the developer, whether daily, weekly, or monthly, to make planning and budgeting easier.

I'd also like the Microsoft Azure DevOps Gantt chart to be improved. We need to see in the schedule how to plan the fields out. We have daily activities and we'd like to use the Gantt chart to make our work approach more successful.

We've been a partner of Microsoft for 10 years, and we've been using Microsoft solutions for 10 years.

Microsoft Azure DevOps is stable. Sometimes there's a little lag, but the next day, it'll work fine. The solution works fine.

Microsoft Azure DevOps is a scalable solution.

Setting up Microsoft Azure DevOps was easy.

We use Microsoft solutions as part of management. We use Microsoft's platform.

We use the latest version of Microsoft Azure DevOps for our projects.

We have 15 people who are in charge of the deployment and maintenance of the solution. Per project, we have one or two developers who utilize Microsoft Azure DevOps: At the beginning, we have the front end developer and the cloud personnel who create the environment, the designer who works to create the right frame, the right materials, the layout, and the design for the project, and at the middle, we have four to five operators.

The platform works well so we didn't have the need to open a ticket or contact Microsoft technical support.

I really like Microsoft Azure DevOps, so I recommend it to people who want to start using it. My advice to them is that it's a huge platform, so it won't be easy the first time. When you test the platform, you need to spend time and make an effort to understand how it works, but it's the best solution. It's the top solution. 

Another advice to new users of Microsoft Azure DevOps is that it's harder to have a macro view of all the processes together. When we needed to cross-match a lot of information from the different processing teams of customers, we found it difficult. You also need to plan well, particularly plan when your developer can work on more than one project. When you have many projects, you need to handle the processes well, e.g. create separate folders for each customer, separate projects, etc., to keep the information separate and be more organized.

Microsoft Azure DevOps could still be improved more, so I'm rating it an eight out of ten.

We are a partner of Microsoft, and we use Microsoft solutions. What we recommend to our customers is for them to use the Microsoft environment, server and databases. We work with some of the solutions and technologies from Microsoft.

We are using Azure DevOps for continuous integration and continuous deployment.

Microsoft Azure DevOps has helped the developers a lot and we are deploying process changes very frequently and simultaneously. A lot of my team members that are developers are updating the code in parallel using Git. Additionally, Microsoft Azure DevOps is providing a very good approval mechanism. Overall it is benefiting by creating efficiency in production deployment and applications, our new releases are running well. The security of secured is good.

We are facing a lot of issues in the development of containerized solutions. We are facing a lot of challenges in this area. They could make the process simpler.

I have been using Microsoft Azure DevOps for approximately four years.

The technical support from Microsoft Azure DevOps is good. Whenever we have raised a ticket with priority, we had a very good response from the technical team. My experience with Microsoft support is very good.

The integrations of Microsoft Azure DevOps are good and the implementation is not difficult. The testing of the solution went well.

I have seen a return on investment from using Microsoft Azure DevOps.

We have spread the knowledge about Microsoft Azure DevOps to a lot of our customers. We have organized a lot of training sessions because we are Microsoft's gold partner. That is why we promote all the tools and technologies which are part of Microsoft and we're also using them.

I rate Microsoft Azure DevOps a nine out of ten.

There are two versions of Azure DevOps: the cloud version and the on-premises version. We use the cloud version in very few situations, but most of our software is based on Azure DevOps on-premises.

We are a software house, and we develop software. We use it to store our source code; that is, it is the repository for our source code.

We have different teams working on different products, and each one uses a different methodology and a different process. Azure DevOps helps with that. For instance, one group may be using Scrum as a methodology to develop their software. The other group could also be using Scrum but with CDCI (continuous development, continuous integration), which helps a lot when you have to develop, test, and deploy the solution.

I think the most usable thing is that you can follow the whole progress of the development process. This makes it very useful for us.

As for improvement, the first one is pricing. For us, luckily because we are partners, it's free. Microsoft gold partners do not have to pay, but if you're not a partner, the product is very expensive.

The second would be that the tool should integrate with some of the competitors. It doesn't matter if it's a big market; it's difficult when you have to integrate with other competitor's tools, like JIRA, for instance.

If you look at the competitor's tools, they integrate easily with Microsoft, but on Microsoft's side, it's not as easy. They have been changing, but still, there are a number of gaps there.

I've got teams that want to use Microsoft Project, not only to control the whole process of the development but also to control the whole project and software. I think Project should be integrated with DevOps.

We have been using this solution for 10 years.

It is very stable. I think the system is down only a couple of hours per year, so it's very stable.

It's very scalable. We started using this solution 10 years ago, and it has evolved, We also have grown our software production, and so far, we have scope with all these situations.

We haven't had any problems with the product, but every time we had some questions, technical support staff answered pretty fast, in less than 24 hours.

The initial setup is pretty easy.

For the deployment, I think we had two people: one person from infrastructure and one who was a specialist in Azure DevOps. For maintenance, because we have about 80 people using this software, we only have one and a half people taking care of the software. That is, the infrastructure person does this part-time. He doesn't spend the whole day taking care of DevOps.

The ROI is very positive for us, but it's difficult to say how it would be if we had to pay for the solution. It's a very worthwhile product, but again, we don't have any comparisons because we don't pay anything for it.

Microsoft Azure DevOps is an expensive solution.

Get to know the product because it is complex and has many different possibilities.

It is worth having it, but you have to have an in-depth understanding and know what it is capable of doing. Otherwise, you're going to install it, and then it will be like having a very nice car in your garage that you don't know how to drive.

On a scale from one to ten, I would rate Microsoft Azure DevOps at eight.

Microsoft Azure DevOps is used for source code versioning, issue tracking, documentation storage, and sharing.

My team likes the integration that Microsoft Azure DevOps has with GitHub and Microsoft Teams. The solution is well integrated with other Microsoft tools in one place, it is very good.

Microsoft Azure DevOps could improve by having better integration with other email servers.

I have been using Microsoft Azure DevOps for a few years.

Microsoft Azure DevOps is quite stable. When we were configuring some continuous integration pipelines, we had some issues, but it was not a large issue.

The solution is scalable enough for what we use it for, we have small teams of approximately 25 people. It's more than enough right now.

We didn't have many incidents to contact the support about. However, they were decent.

I was previously using Jira.

The initial setup is straightforward. The configuration of Microsoft Azure DevOps could be better. The documentation needs to be improved.

The implementation and maintenance of the solution are done by our DevOps department.

We do not pay licenses for this solution.

I would recommend this solution to others.

I rate Microsoft Azure DevOps an eight out of ten.