Customizing JIRA should be considered as a project in itself. It's quite easy to start making changes while configuring JIRA, but you should always plan your customizations first and document them.
You can perform these steps to begin the customization process:
Moving to a new tool always faces resistance from users. JIRA is no exception; however, JIRA has the advantage of being intuitive and it allows you to have a clear distinction between usage and administrative sections. When deploying JIRA for the first time, always use the default configurations and ask users to test it for a few days. This will make sure that users first get comfortable with the features that come with JIRA out of the box. This piloting should ideally be done for at least one candidate from each team, consisting of a project manager, project lead, developer, and tester.
At the end of the pilot phase, ask the users to give their feedback. The following questions can be asked in the feedback form:
- Were the default Issue Types sufficient for your project?
- What changes would you like to perform in the workflow?
- Were the default fields enough to capture the information?
- Do you want e-mail notifications?
- How many types of users will be using JIRA?
- Do you want some users to have restricted access?
- Do you want e-mail notifications?
- What kind of reports would you like to have?
The answers to these important questions will give you a very good understanding of desired customizations from various stakeholders in the project.
Merely collecting the feedback is not enough to start the customizations. It's very important to first document these customizations in a document to describe the requirements.
We discussed in detail how to gather the requirements in Chapter 5, Sample Implementation of Use Cases. Ideally, a separate document for each use case should be prepared. This document should be updated before making any changes in the system. This will ensure that if a new JIRA administrator joins the company, he/she will not have any problem understanding JIRA's customizations.
Once this document is prepared, share it with the stakeholders and ask them to give their inputs. Organize a meeting with them to fine-tune the requirements and make necessary changes in this document. Eventually, this document should have the details of all the actual customizations that will be performed in JIRA. What new issue types need to be created, workflows should be visualized in the documents along with the new states that need to be created, and permission schemes and notification schemes should also be mentioned.
Once the requirements are finalized, you should test them on a test environment first. For this, set up a sandbox JIRA instance (which is an exact copy of your production). All the new and old changes in the existing configuration should first be tested on the sandbox. It's really important to have the sandbox for cases when JIRA needs to be upgraded to a new version and when you want to evaluate a new plugin.
The sandbox, which is an exact copy of production, will give the stakeholder a chance to test their requested customizations without worrying about any damages that they could have done on production.
During this testing phase, the stakeholders will surely give you a lot of feedback and ask you to improvise certain customizations that they earlier couldn't perceive. Note down all these changes and make necessary amendments in the document.
Once the implementation is successful on the test environment, you can then perform the customizations manually on production. At this time, the JIRA administrator will have all the information in front of him in the JIRA configuration document. Making actual implementation on production will not take much time.
However, if you are making any changes in the JIRA instance, which is already being used by several users, then it's a good idea to first notify them with the change. You can write a short release note and mention the changes that are done. This will not surprise the users with unexpected changes. Applying changes in the configurations usually doesn't require any downtime, but sometimes if you make changes in the workflow, then it's always a good idea to do it when no one is using the instance. For this matter, notify users of a downtime well in advance.
JIRA has a wide range of applications. It's an issue tracking and project management tool. This tool can be used not only for bug tracking, but also for test management, helpdesk, requirement management, and Agile tracking.
Now, initially when JIRA is implemented, it will be customized for a specific use case for one or more projects, but eventually as more teams start using JIRA, they will request for more customizations. JIRA allows you to use the same configurations in multiple projects, but when the number of projects grows, the same schemes cannot be used for all. So, it becomes very important to standardize your configurations in JIRA and ask the new teams to follow it.
Let's take a look at the following scenario in JIRA with three different use cases:
|
Use case |
Number of projects |
|---|---|
|
Test management |
10 |
|
Helpdesk |
5 |
|
Requirements management |
2 |
As you can see in the preceding table, there are multiple projects using the same configuration. Now, one of the project managers using the test management scheme may request you to add a new custom field in his/her project or to make one of the existing fields mandatory. Now, these minor customizations will affect all the other projects using the same configurations. We can limit these customizations to a single project by creating a new set of schemes, but this will lead to more maintenance for a JIRA administrator.
Avoid creating multiple schemes for the same use case, and before accepting any change in the existing configurations, discuss with the stakeholders of all the projects using that configuration. If one project manager requests for an additional custom field, then discuss this with other project managers and make the changes after confirmation from all the stakeholders.
So, it's very important to standardize your configurations as much as possible and reuse these configurations in other projects.
In Chapter 4, Customizing JIRA for Test Management, and Chapter 5, Sample Implementation of Use Cases, we discussed how to customize JIRA in detail along with various examples.
JIRA administrators have the responsibility of implementing customization requests. As discussed in the previous section, configurations should be standardized as much as possible, but sometimes changes need to be done in JIRA to support JIRA's requirements; any change, be it small or big, needs to be analyzed first because it may lead to further issues. I recommend a Change Control Board whose job is to study the customizations before implementing them.
I recommend the following process:
- Create a project in JIRA for support requests with various issue types, bug, improvements, and new feature.
- Ask your users to raise a ticket in this project for any JIRA support.
- Once the ticket is created, analyze the requested customizations and perform an impact analysis.
- If there is no impact, then implement the changes directly in JIRA.
- If there is any impact on other projects, then discuss the changes with the stakeholders of other projects.
- On the basis of your discussion with stakeholders, make a decision on whether or not to implement the change in JIRA.
Let's take a look at some of the customization requests from users and their possible impact on the instance:
|
Request |
Used by other projects? |
Impact |
Conclusion |
|---|---|---|---|
|
Addition on a new custom field |
Yes |
Minor |
This confirms with other stakeholders first |
|
Addition of new values in a select list custom field |
Yes |
Minor |
This either confirms with other stakeholders or uses context to create a different set of values for that project |
|
Change the workflow condition |
Yes |
Major |
This is a major change and should be discussed with all stakeholders |
|
Addition of a new workflow state |
Yes |
Major |
This is a major change and should be discussed with all stakeholders |
|
Create a mandatory custom field |
Yes |
Major |
This is a major change and should be discussed with all stakeholders |
|
Installing a new plugin |
Yes, applicable globally |
Major |
This installs the plugin first on sandbox and asks the stakeholders to evaluate |
|
Creation of new issue type |
Yes |
Major |
This discusses the need of this new issue type with all stakeholders |
These are some examples of requests that JIRA administrators will receive. For each request, analyze the impact first before implementing it in the system.