Judging JIRA Software
Jonathan Mendelson | TrustRadius Reviewer
October 26, 2017

Judging JIRA Software

Score 6 out of 10
Vetted Review
Verified User
Review Source

Overall Satisfaction with JIRA Software

We use JIRA as our primary development tool for bug tracking as well as for Agile process management. Combined with Confluence, nearly all of our SDLC is managed within JIRA and Confluence (the latter being an extension of JIRA for documentation that is longer than convenient to fit into a single ticket). This tool is used primarily by engineering and product, but users in marketing and design also participate too.
  • It is a well-known and recognized issue tracking tool.
  • It is extremely customizable, both in terms of customization of the tickets themselves as well as how one can apply workflows to manage your process.
  • Given its wide usage in the market, there are a number of 3rd party plugins/integrations available for JIRA; you can tie it to your repository and have an integrated view of development within the issue tracking tool (for example).
  • Atlassian recently made a number of UI changes to both JIRA and Confluence. The Confluence changes negatively impact productivity by hampering what used to be a relatively straightforward navigation process. JIRA received an analogous set of changes; while less egregious, I find the new look increases my eye strain when trying to find needed information. New users may not have as much difficulty, but you should try it for yourself.
  • Atlassian offers both a Cloud and on-premise solution; the Cloud version doesn't offer many customizations and plugins that are present on the on-prem (server) version.
  • The amount of customization offered by JIRA is a blessing and a curse. Generally speaking, it's important to keep things as simple as possible; avoid adding custom fields or super involved workflows as much as possible (though the default workflow doesn't work in most situations based upon my experience).
  • You'll need to nominate someone in your organization to own the JIRA effort -- this person should have a reasonable knowledge of JIRA administration but also have the ability to fairly present options and solutions as issues arise. If you don't have someone in this org but opt for a committee of sorts your instance can become a true mess and will negatively impact productivity.
  • Sprints management is relatively simple and straightforward.
  • As our organization matures, we will be able to take more advantage of JIRA's reporting tools to help us refine our processes.
  • By keeping things relatively simple and transparent (everyone can view all tickets -- no crazy permission schemes), the entire org has visibility into our development process.
JIRA was already in place; there wasn't a good reason to switch to something else. We just needed to work on refining our processes and clean up the existing structure so that we could make progress on our SDLC while getting our MVP out the door. If you are really starting from scratch, you'll want to try all options out yourself... but it's hard to really compare/test drive in a vacuum. I'd suggest that you settle on something that most members of your team can live with.
If you are a strict Agile devotee, JIRA will disappoint you -- Atlassian has a very specific interpretation of how to run Agile and it's not necessarily for everyone. However, having implemented an SDLC in three different companies based upon JIRA I've grown confident that few companies are so rigid in their interpretation of these rules such that JIRA is a good option. Keep in mind your team size -- it gets pricey as your team grows (they know that they have you locked in).