Atlassian ALM Reviews

I have been using Atlassian ALM for twenty-five years. It used to be called Quality Center, and I first used it in 2000 and 2001. The company changed, but the product remained. Atlassian ALM has not benefited my workflow regarding the use of third-party plugins.

The interface between the repository and test plan stands out as valuable. I appreciate building the tests and scenarios in Test Lab, and the ability to link defects throughout the system. Atlassian ALM does this better than any other testing products.

I am still not satisfied with the requirements area of Atlassian ALM. Atlassian ALM has four parts: test plan, Test Lab, requirements, and reporting. The requirements portion continues to be an area where I am not happy.

I have an overall experience in this field of more than 25 years as a Program Test Manager.

I would rate the technical support of Atlassian as a seven on a scale from one to ten.

Positive

The deployment depends on whether you are deploying it on your computer or across the program. Cloud-based system deployment takes some time, as it depends on your rights to your computer. I would rate the deployment as a seven on a scale of one to ten. It took a couple of hours to get it right. The IT department deploys it.

Positive

I do not know the exact number of people involved, as it depends on the IT department. Since I am a contractor who works and consults in big companies, I estimate approximately ten IT people were involved.

I have not personally experienced financial benefits, but there may be kickbacks from the company regarding any financial benefit or return on investment after implementing the product.

Atlassian ALM is too expensive. The pricing is very expensive.

I do not use Jira for issue resolution, and I have not utilized Confluence for documentation.

I am using Atlassian ALM as the only product. I am not working with solutions from OpenText or IBM. I do not use those plugins. I am working with the cloud deployment model. I have an overall experience in this field of more than 25 years as a Program Test Manager and an Independent Program Test Manager. I work in numerous companies and was at Reckitt six years ago. I am satisfied with future updates and features for the product. My overall review rating for this product is eight.

That is not correct; I would recommend Atlassian ALM for cases at the right scale. I have been implementing FDA regulated medical or medicine development with Atlassian ALM. The whole requirement management chain with Jira and Confluence means that auditors accepted everything and it was fine. It is possible to do, but it is totally on the upper limit. If you develop a SaaS service or business-to-business CRM, then it is definitely enough to use for requirements. Still, you need to have requirements. For example, if you handle payments or need proper formal requirement management to get reports, you can do that with Jira with some applications such as Requirements for Jira, which R4J is one of them.

You can extend Jira so it has traceability, baselining, and reports. However, it is not really scalable, so if you want to use it for anything larger or plan to use it for product portfolios, then it starts to be problematic. Definitely, it is much easier to use, and if you can spend the little effort to configure Jira to support your more complex requirements management, then you can concentrate everything in one tool. You do not need an additional requirements management tool and the whole company tool chain is simplified in architecture and all.

For sure, that is the thing with Atlassian ALM: you just go to the marketplace and put the plugins and you are integrated, whatever.

If I need to give it a grade on requirement management especially, I would put it at six or seven, probably six.

Limited features and scalability are the reason I give Atlassian ALM a six or seven out of ten.

They could have proper structure so that you can have document type structuring of the requirement and reuse of requirements and linking. You can do links in Jira, but you cannot manage them as in other tools. I would put Atlassian ALM at six because then you could get seven if you put all possible plugins and configure it for about one month. Out of the box, it is something around six.

It is getting higher all the time with Atlassian ALM, but it is relatively much lower than the competitors still. They have AI features already built in and many other things. They have open pricing, and you can see the prices on the website.

That is good; I would say that is how it should be with Atlassian ALM. It is not super fast, but it is constant. They have so much documentation out there that it is quite rare that you need to contact support because you know the answer already by searching online. This is totally missing from IBM because they have hidden their documentation mostly, and then online searches do not give you any answers.

I would put even nine out of ten for Atlassian ALM. Most of the things that people are annoyed about is that others have not even gone into that. They publish their development roadmap, and then people debate what shall be developed next and so on. There is much discussion, but the other vendors do not even publish their roadmaps, so you cannot have any discussion. I give this review an overall rating of six out of ten.

The most common use case is for software development teams. Some clients also use it for their service teams, like the service desk. 

Additionally, we have some clients from the sales team who use it as a sales enablement tool.

The most valuable feature is the Scrum board.

There is room for improvement in the high-level project management.

In future releases, I would like to have a planning feature for high-level project management.

I've been working with Atlassian ALM for about seven years. We're using almost the latest version.

I would rate it as a seven in terms of stability. I consider it stable but not the highest level of stability.

We have both small-sized and big-sized customers. The small ones generally have around 50 to 200 users. The larger ones, for example, in China, have around 15,000 platform users. So, the number of small companies is high, but the total business value comes from the big companies. 

Atlassian ALM can handle different user volumes. For customers with more than 500 users, we recommend deploying a high availability (HA) architecture. The solution supports both single-node and HA modes.

I would rate the scalability a five out of ten. It could be better in terms of scalability with more users. It could be improved to better handle larger numbers of users.

We have clients using Atlassian ALM both in China and globally. We have around 20 clients using this solution. 

I'm somewhat surprised by their support for our clients. From an administrative perspective, their support is not very fast.

Neutral

I would rate my experience with the initial setup a four out of ten, where one is difficult and ten is easy to set up. It's not so easy to initialize. The setup requires professional assistance. 

This solution is deployed both on-prem and on the cloud. It's a global mix, with around half being on-premises and the other half on the cloud. Atlassian provides a cloud platform for clients to connect to.

The deployment took two working days. Generally, we need to clarify with the customer's network engineer. They are the infrastructure engineers who prepare the network design and hardware design, and then we install the whole system. Next, we collect information about the customer's processes and prepare the solution. We provide them with system configurations. Typically, about half of the customers require on-site training based on the solution. We assist customers with their questions and provide consulting, training, and workshops to improve their processes during the initial year of usage.

The pricing is on the higher side. I would give it an eight out of ten, where one is low, and ten is high.

We primarily focus on Atlassian ALM, but we also explore other solutions like Microsoft ALM and CodeBeamer ALM.

I would definitely recommend using this solution. 

Overall, I would rate it a nine out of ten. 

Our primary use case is to have as an ALM Software. We develop Software, so we need to have a solution that supports the full cycle of the software development, starting from the requirements to work management, to source code management, to being tested. And on top of that, we have sharing capabilities with Confluence.

The main power of this tool is the integration between the different products of the Atlassian suite. We have good integration with work management and Software build automation (Bamboo).This is the major strength from this provider. 

For project management, the scheduling of the project tasks should be simplified because it's complex and too rigid using the Atlassian Portfolio . 

I have been using Atlassian for fifteen years.

I haven't experienced any problems with stability.

Scalability is very good. We have more than 10k users. It's being used a lot. 

The majorty of the users are software developers.

Their technical support is very good and easy to work with. 

I didn't do the setup but the most important part is identifying how the model from Atlassian will fit with our operational model. That is the key part. 

My first recommendation would be to think about what you want to use the data modeling for? Do you want to have organization per project, per customer, per product, per business? This is my recommendation, think about how to make the modeling work with what you want to do.

The scheduling feature is too complex. They should make the project management part of the course plan activity easier.

I would rate it a nine out of ten.

The primary use of this solution is agile application life cycle management.

This solution fits very well into our agile product management environment.

The most valuable feature is the integration with the other Atlassian products such as Bitbucket, Confluence, and HipChat.

The current method for dealing with requirements management involves another solution, which is costing more for the users. Traceability between higher level and lower level requirements in the hierarchy is something else that is not fully addressed. It would be helpful to have requirements management and traceability functionality built into this solution.

The reports are not really customizable, which is something that they should improve on. The reporting capabilities, in general, are in need of improvement.

I have been using Atlassian ALM for more than three years.

The solution is stable but at times, the performance is poor. It takes time to load and the response time is not up to the mark. We use this tool frequently and all of our project work gets done through it.

This is a scalable solution. In my previous project, we had more than 1,000 people using it. These people are end-users who have been allocated to the project. For example, they could be developers or testers.

I would rate them very good in terms of support. The only issues that we have had are that some plugins are not available.

The initial setup is straightforward. Once you get access to the instance, through the cloud, all you need to do is log in using the credentials. The configuration takes time because it has a very heavy interface with a lot of apps in it, but we find it very user-friendly.

There is a community edition available, but if the price were lower for the addons then more people would use the full version.

Atlassian is a market leader in this segment and I would definitely recommend this solution. I would just like to see more of the features available at a more reasonable cost, which would keep more people from going to the community version.

This is a good solution, but the main thing we want to see is better traceability between epics, features and stories. As it is now, there are only two levels. The link is between an epic and a story or an epic and a feature.

I would rate this solution an eight out of ten.

The Atlassian ALM suite consists at least of JIRA, Confluence, BitBucket and HipChat - just the tools you need for organizing your teams in a very efficient way. The most valuable part might be that those tools play very well with each other. 

JIRA lets you work within projects for organizing your work, while Confluence gives you all the tools you need for documentation work. If wanted, you are able to link Confluence pages to JIRA issues and vice versa. This helps a lot if you need to work across teams or sites or even countries.

Using BitBucket, you could organize your code within projects and repositories. It is also possible to refer to a specific JIRA issue within the commit messages, which uses JIRA to link a specific commit to a JIRA issue. Within the JIRA issue, all commits can be seen and direct links to BitBucket show the viewer the related changes within the code. In addition, even pull requests (and the discussions inside) can be linked with a JIRA issue.

If your team needs to discuss certain aspects of the code, you could either use the comment feature within JIRA or create a channel for the issue within HipChat - and just chat. The chat log will be linked to the JIRA issue, which means that any viewer will be able to comprehend why you implemented a specific feature, for example.

Another very valuable aspect is that Atlassian lets you download all products and host them within your own site. This is very important for companies where data control and data safety are part of the company policies.

The suite helped to make the work within teams and across teams more efficient. Members of other teams might just look at your code and look up the related JIRA issue or Confluence page since they are linked together. The staff no longer needs to search for the related information because it is presented right away.

All Atlassian products are based on JAVA which makes it a bit difficult to trace problems if you don't have much JAVA skilled staff around. You can try to read the error messages and understand what's going on, in some cases you might succeed even without Java skills. In other cases, it makes sense to search the web for solutions. Since Atlassian has a very good Q&A site and online documentation, changes are high that you might find helpful hints online.

Furthermore, Atlassian should provide a product which helps you back up and restore all related data.

With Confluence, the most valuable feature for me is when I tag a ticket in JIRA, Confluence becomes aware of the ticket's status. Bitbucket automatically links them, but I haven't found that to be particularly useful. If I open a pull request, Bitbucket is not good at giving me a link to JIRA, which is something that I would expect it to be smarter about.

In Bitbucket, the reviews are pretty good. It does a good job of picking things up. The review interface is great. It makes super-clear who's making comments, what people are commenting about, and inline comments. The diffs are relatively clear. It does a good job keeping track of which comments are still relevant, and which aren't.

The tasks feature is pretty nice, where you can open a task in a pull request and it'll stop you from merging it until you have completed the task. It's relatively nice and configurable to work with Jenkins and similar tools.

I use JIRA and Bitbucket for the same work. I feel they're really quite separate tools and do different things.

The connection between JIRA, Bitbucket and Confluence feels like an afterthought. In Confluence, if I'm documenting some meeting, then I can tag the tickets and easily see the status, which is nice, but it's not like a super big deal.

I use all three products, but the interaction between them isn't extremely helpful. I haven't found any useful way of integrating Bitbucket with Confluence.

I struggle to get people to write anything of any significance on Confluence, though, because the editor is so painful to use. We end up writing anything that's a living, important document in Google Docs, and then we link to it from Confluence. It's ridiculous because Google Docs is a terrible tool in a lot of respects. Confluence is just a super-inadequate tool for editing documents.

Confluence is a pretty good tool, but people refuse to edit documents in there, because the editor just doesn't work half the time. That's a real problem, because it's supposed to be the central place in the organization where we share information between all the teams. People don't want to put documents in there, because it takes them forever to edit them.

It seems like that's really the most basic piece of functionality that a tool like Confluence should offer, and it does it extremely badly. It seems like the core part of its offering is that it can create a document and edit it, so people can find it and read it.

JIRA offers a lot of configurability, which for upper-level management is nice because they can enforce whatever policies they want to be enforcing, and get good visibility. Because it's so configurable, as a developer using it, there's just much more complexity than you want on a day-to-day level.

If I could get away with using Trello, for instance, I would, but I do see that it doesn't provide functionality that the business needs. As a developer on a day-to-day level, JIRA's a pain in the neck.

I see now that I can actually jump straight into the ticket in JIRA, and see the description. It might be nice if the definition of done from the ticket in JIRA was more prominently visible in the pull request in Bitbucket. Now that I know the link's there, maybe we'll use it.

JIRA's slow to boot, so we end up wasting a good chuck of time waiting for JIRA to load. It shows me much more configuration information than I really need it to. It shows me many more fields than I need it do, which makes it hard to find what I'm looking for. My team went through something like three different ways of working with JIRA in three months, and had to continually find the correct dashboard. For JIRA to be an enjoyable experience, you need to invest in becoming a JIRA expert. Most people would prefer that they didn't have to think about using this tool, and it just worked. When you're selling it, I'm sure it's great because it has every possible feature. For the one or two JIRA experts in the organization, I'm sure it feels like a great tool. To the end user, it's so over-packed with features, that it's just overwhelming to use.

It would be a big benefit if the super-experts at JIRA in your organization hid all the configurability and all the unneeded features from the rest of the users, so that you could use the tool without thinking about it.

Bitbucket's great.

Simplify how you use JIRA as much as you possibly can. Make sure you have a workflow that fits your organization and make sure the people in the organization understand the workflow.

For a number of internal business processes like hirings, employee transfers, changes of pay, and approval of commercial documents, we run them all through JIRA workflows.

We're starting to push the boundaries of what we can do with Atlassian ALM. It's served us pretty well and we like the flexibility of being able to create custom issues, fields, etc. We've invested in a number of add-ons to give us additional functionalities with JIRA and Confluence, the latter of which is our de facto documentation tool for living documents (stories, reference information, procedures, etc.). We're able to take advantage of the integrations between JIRA and Confluence, for example to show a list of JIRA issues on a Confluence page, and vice versa.

Also, we've invested in Stash, which is our repository for any software development we do. There's not a lot of integration from Stash to JIRA and Confluence that we use. Obviously, we can track bugs and link them back to comments in Stash, but Stash is mostly a standalone solution for us.

We're hosting JIRA, Confluence, and Stash in the cloud with AWS.

My job is to make sure these things meet the needs of the users. What I'd love to be able to do is actually stop hosting these things ourselves and just go across to the Atlassian Cloud version of these products. I've used those in the past and the integration between JIRA and Confluenc, is a much tighter, neater experience. This is particularly important when you get to managing users and so forth. It's a more seamless experience for users between those two products.

But we just can't do that because Atlassian has no practical solution for enterprise identity management. Essentially if you want to use these products you have manage your users and their roles / groups within the Atlassian ecosystem, which is completely impractical for a business of any size.

Since we host our own server instances, we are also responsible for the product upgrades. It's probably the biggest challenge for us. Frankly it's a really daunting exercise - challenging, problematic and very flaky.

Even if you can upgrade the core product, compatibility with the existing plug-ins is questionable.If you do a major version upgrade, more often than not, you'll find that some of the plug-ins you previously had working have stopped working. We have struggled to stay current on the Atlassian products because these upgrades are such a drawn-out exercise.

The main products we use right now are JIRA, Confluence and Stash or Bitbucket Server as they now call it. We, up until recently, also used HipChat but have recently turned that off in favor of Slack. Sorry Altassian, you've lost on that one. There is a message there for you, Altassian. We've actually been using, particularly JIRA and Confluence, for quite a few years. We're generally big fans. We use it actively, we promote it to our clients, we use it to manage our client engagements. We actually do consult engagements occasionally to set up Altassian products for our clients. Ironically, Altassian is also one of our clients so we've, at times, provided a consulting service to those guys.

Their Sydney office is right next door to us, so it's pretty close knit. You know JIRA is, at its heart, a project management system. Our business is providing professional consulting services in the space of software engineering. We use that to manage the software projects and we run our engagements in an agile style using Scrum by default. We've got dozens and dozens and dozens of projects that are essentially Scrum. It works pretty well. We use, beyond that, JIRA as our de facto enterprise to-do list.

We struggled to get performance out of JIRA and Confluence, in particular. Even though we've done quite a lot of profiling and upped the instant size of the EC2 servers that we're running this thing on, it feels sluggish. You're navigating around and it's not snappy. That's a bit of a challenge at times, particularly in Confluence, because you can get these runaway background processes that can massively impact performance.

One of the things that we've found is we've revoked pretty much every user's right to export a space in Confluence. Before you do that, you can just basically kill the entire platform while that's running. There's no practical solution right now for a custom HA-type solution. I know Atlassian actually does that internally, but I've heard of extremely flaky instance.

To try and have a good, healthy HA type configuration, there's still quite a way to go there. Those two products are probably one or more critical systems for our business so it's a bit of a challenge.

Generally, it's been a really good experience. They're pretty responsive. I personally don't make the calls since I've got guys who do that for me. Following an alarm, it can take a bit of back and forth to figure out what the problem is and if there's a solution for it. Generally, they don't blow you off and their first response assumes that there is a problem, rather than the user's an idiot. I don't think they just follow the script and say the "format the hard drive and call me in the morning"-type nonsense.

It's ancient history, to be honest. We've been running these instances for so long now. I've contemplated whether we should do a clean install. Essentially, the way you do an upgrade is you fire up the new instance and it upgrades and runs a bunch schema updates to update the database. You've got layers and layers and layers of schema changes and a lot of crud, crap and corruption is left in there after six or seven years of doing that. I couldn't speak to the original.

Atlassian is talking to me about starting to try and think about their products working together as I mentioned before. It's like an ALM-like stack.

As a general purpose tool, JIRA and Confluence are still ahead of the competition. I'd say, your first decision is to try and figure out whether you can get away with using the Atlassian On-Demand versions of the products. If you can, go that route rather than hosting your own. Just get the thing up and running, get a few users, get one team on there, and get a couple of projects.

Launch with an MVP of your Atlassian suite and then iterate. It's pretty easy to manage and enhance the configuration of the thing while it's live and users are using it.