Atlassian ALM Reviews

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.

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. 

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

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

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 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.

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.