What are common themes you've seen across successful & failed Jira Software implementations?

Hey everyone! My name is Sarah Schuster, and I'm a Customer Success Manager in Atlassian specializing in Jira Software Cloud. Over the next few weeks I will be posting discussion topics (8 total) to get your expert advice to help new or first-time Jira Software Admins be successful. This advice will be incorporated into our inaugural New Jira Software (Cloud) Administrator Playbook (release date: Spring 2018) - we are all so excited!

I'm amazed at the responses seen for the first thread topic, and I'm hoping to get your expertise on this week's topic: Jira Software Implementation Success

So discussion topic #2 (of 8): What are common themes you've seen across successful & failed Jira Software implementations?


Let us know below!



Let me start off with a handful of good and bad things I've seen over the last few years - Jira Software Cloud focused - I focus on the application over the more organisational aspects like a good Scrum Master and following Agile Practices correctly ;):


  • Using Dashboards and creating Dashboards for each of the Roles in your Projects, which presents relevant information to them for their Job Role.
  • Using Agile Boards with appropriately customised options (Issue Detail View, Card Layout and Swimlanes) and knowing when to separate into multiple Boards.
  • Use a planning plugin (e.g. Planning Poker) to start increasing your teams' abilities in estimating work correctly.
  • Using Jira Portfolio or Structure to plan at the portfolio level and trace from theme/initiative level down to the story/task level.
  • Jira Installations with a dedicated individual or team managing the system and ensuring that changes are consistent.
  • If using a testing plugin, use one with traceability from requirements (e.g. Stories), to Test Cases, Test Executions and finally to Defects.


  • Users/Teams unwilling to standardise business processes - e.g. your company has 20 different development teams and each of them has their own Workflow, Custom Fields and Board configuration.
    • This acts as a barrier to entry for users to change teams and makes administration more complicated.
  • Installations allowing users to be administrators or 'temporary administrators' of the system without formal training or certification.
    • Building up Technical Debt (e.g. making changes quickly/sloppily for an important member of staff) is worse than investing the time to do it properly (schemes!)
  • Misunderstanding the Quick Filter functionality. e.g. having a list of 40 different Quick Filters instead of (a) Different Boards or (b) Dynamic Filters (e.g. currentUser()).
  • Too Many Custom Fields, Unused Custom Fields, Incorrect Scoped Custom Fields, Duplicate Named Custom Fields :) - not only is it confusing, but you are actually impacting the performance of your system with these mistakes!

Look forward to hearing more successes and failures.

Some of our teams failures have stemmed from various teams having their own workflows, screens etc; however, they want to share issues on boards etc. :(

Success comes from adoption.  Seek first to know what your most valuable users want/ need and shape the system to deliver.  If you show them cool features, that aren't needed, it won't get adopted.  

The Dashboards are a great feature for this.  With a Dashboard, you can show a widget or a burndown or a status or really anything.  It's best to show the new users what they want more than cool new JQL queries ;)  

As the team learns how it enables their work, they'll find new ways to grow with the product.  


Another great aspect is to bringing to light know issues with data.  There are many ways to highlight this within JIRA.  For those teams who aren't in a position to speak truth to power, this can be a tool to 'ease in' the need to do work in a different way.  

For example, while watching the process flow, it becomes apparent that an entire quality control step could be moved up stream to save precious downstream build times.  This information might not have become visible without a dedicated focus.  

You can export your JIRA tickets into a simple .csv file for further review and analysis.  (This really helps with LOTS of tickets )


Failed installs usually happen because someone is 'told' to install JIRA and Confluence, and they get installed on the same database, and then it's slow, and then people complain...

Make sure you install with dedicated databases (it's easy, there's documentation)  and reach out early for help.  We're all on the same team!

If the people involved start to separate their processes, it's gone. So a great lead is obviously necessary. As soon as an instance starts to "split up" their processes, the trouble begins.

This hasn't been an issue for us.

We have several differnet workflows to choose from.  Some people use the very basic default scheme.  Then we have a software development lifecycle workflow scheme, and another one for groups that are doing non-software requests (ex: install a server, modify a router, etc).


When you get your project set up, you request the workflow scheme you want and it's been working fine.

Agreed - every workflow, screen/permission scheme, dashboard, scrum/kanban board etc does not have to be the same; however, you don't want too many customizations either.  Depending on the size of your instance you may want to provide guidelines and a few options team can elect without creating a nightmare for admins or new users by allowing it to be a free for all.

The tool doesn't work if you don't have defined processes (the tool is only as good as the process). The biggest hurdle for my company was changing the culture to better understand that any decisions should be based on the balanced team vs the individual resource. Getting teams to adopt some sort of standards to assist with consistency added to the challenges. Additionally, I didn't find themes beneficial outside of Portfolio.

In terms of "implementation", the word seems to mean end-to-end, so I will just focus on the actual usage of JIRA Software.  

For me, the biggest challenge begins with Admins, not the users.  The Admin(s) manages users, permissions, projects, issue configuration (workflow,screen,custom fields), and best practices.  

Whether it's a full-time role, or a part-time role, the Admin must not only be the go-to person, but he/she needs to be an Evangelist for the software.  

Beginning with that point, here are my top challenges (and failures)

  • Right person, Right role OR Wrong Person, Wrong Role - the Admin must be the right person.   They will drive training, best practices, usability, and overall efficiency.  An Admin without the necessary skills/experience could have a negative impact on all users, if they don't know how to manage issue types, workflows, schemes, custom fields, and most of all promote re-usability.   
  • Simplicity vs. Complexity - This is where a "project lead" often believes a more complex project with complex workflows is always better.   In reality, a few issue types, simple workflows are usually better, even for advanced software development teams.  This is really a mindset problem with "project leads" and users.  
  • Leveraging Core Features - Too often, users don't seem to know the core features available to them, from JQL, filters (subscription), and especially dashboards.  Another feature is Components, and teams often do not leverage the capability such as default assignee.  
  • Content of a single JIRA issue - This is all about best practice, and again it begins with the Admin or "Evangelist".   Poorly created issues are everywhere.  This may never be perfect, but with proper training, users can improve quality and readability of their Subject,Description, and Comments.  

I'm not sure if this was the response you were looking for, but it was fresh on my mind.  

Too conclude, the Admin's job is not done after the software installation, it is just beginning.  They need to be an Evangelist, a Coach, a Trainer, and a JIRA expert.  

Having the same screen open when a user logs back into the system, instead of defaulting to the Dashboard or filter. Is this a permission issue? 

- Users solving issues without even using the Workflow or adjusting statuses. Therefore often smo doesn't even know in wich status a issue is really

- Using the comment function to adjust requirements needed or specify further requirements

- Using fields and screens when they are needed. Request the information you need at the right spot/status instead of overfilling the screens with information smo cannot give --> empty fields

"Using the comment function to adjust requirements needed or specify further requirements"  --aAAAAAAARRGHHH!!!!!   agreed.

Pedro Felgueiras Community Champion Feb 16, 2018

We have what i can consider a successful implementation of Jira. 

The major aspect that help us a lot in the implementation was that the previous tool that we use (Lotus Notes) was horrible, outdated and without knowledgeable administrator of it. 

The first progress that we had implemented was the ITIL for incidents and requests. We had the help of a ITIL consultant that, with us, defined the process without thinking on any limitations of the tools that we will use. The pilot started with a small client and a open mind team. After fixing some aspects identified on the pilot, a migration schedule was define and implemented without questions and doubts. Because of the struggles with the previous tool all collaborators realized the added value and help us with valid suggestions.

After that, the other teams develop interest in Jira, and the ask us for implementing Jira for them. 

Because of the error prof that the humans are susceptible the workflows were constrained and restricted to try to minimize the incoherence between issues. 

Now, all the teams use Jira and are happy with it. 

We have some problems with the oldest collaborators that are resistant to changes but when hey had seen the advantages they become convinced. 

We recently covered this topic on the Valiantys blog. Essentially, here are a few tips to keep in mind: 

  • Limit the number of admins to avoid having too many cooks in the kitchen. 
  • Make sure your team adopts the tool rather than fall back to email. 
  • Keep the workflow simple and have a final status. 
  • Contextualize your custom fields. This will help your JQL search retrieve the right custom field (instead of twelve if you have twelve different projects...).

The search functionality is pretty sloppy.

Why can't I type JQL right into the basic search bar? If I do it, then I get an empty search result. e.g., if you type: "project=XXX and status!=closed" into the search bar, then the outcome will be "text ~ "project=XXX and status!=closed"" and obviously that leads to an empty search result. 
Search bar should work natively with JQL; no need to wrap it with the "text~" tag.


Log in or Join to comment
Community showcase
Alexey Matveev
Published Saturday in Jira

How to run Jira in a docker container

Everything below is tested on Ubuntu 17.10. I prefer to use Jira in a docker container because: 1. I can install Jira with a couple of commands. 2. I can start and stop Jira just by starting and s...

538 views 6 9
Read article

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you
Atlassian Team Tour

Join us on the Team Tour

We're bringing product updates and pro tips on teamwork to ten cities around the world.

Save your spot