As @Bridget mentioned - it is spring in Australia, time for house cleaning. Well, we, Europeans are half a year behind or forward (depends on perspective), but it does not matter. Rules of the game are the same.
So, let's talk on Jira cleaning
First things first - why would you do the cleaning? There might be several factors for, but two are the most important:
- governance - within it I would include security, unification, change control, program/project control, users and admins review etc.
- performance - within it I would include availability and capacity, utility of tools and so on
Your focus on what is more important might fluctuate, depending on actual, current needs and goals. Still, both need to be taken into consideration. Why? Proper governance cleaning will allow You to keep/improve performance measures, while proper performance based cleaning might affect governance by changing known, approved ways of working.
I did my time for one of the project running huge performance analysis for Jira DC instance. Instance performance was terrible, governance even worse. And first advise given was to clean it. Get rid of 75-80% of 1200+ workflows, 3000+ custom Fields, and a lot of other stuff. But to clean it wisely - was another challenge. We have spent 9 weeks on analysing thoroughly all aspects - from underlying infrastructure through architecture, technical and business configuration, ending up at usage patterns. For the purpose of this article I will leave behind Architecture and technical part, and focus on business config cleaning and usage patterns.
Business config cleaning
As You might know from Atlassian documentation there are multiple factors You need to maintain clean:
- Workflows & Workflow schemes
- Custom Fields, contexts, configuration schemes
- Screens and screen schemes (including Issue Types screen schemes)
- Permission schemes
- Notification Schemes
- Security Schemes
- Priorities, Resolutions, Statuses etc.
- Shared objects - JQL filters, filter subscriptions, dashboards, gadgets
What does it mean "keep it clean"? By my means - keep it as functional as You need, but structured, unified as possible, re-usable. Jira gives You great capability, as the open platform, to make every project uniquely configured. But gives you also even more important option - to reutilise and unify ways of working.
If I recall example above - instance with 1200+ workflows - 800+ of them were THE SAME workflow. used in different projects. Exactly the same, out of the box workflow. By using shared configuration You would downgrade volumetric of active workflows by 2/3s. Governance wise, and performance wise.
Keeping the same example - avoid and correct need from admins, project admins, change requestors to leave their unique "legacy". In 3000+ custom fields in mentioned instance around 120 were different fields for "results description": analysis results, test results, QA results, UAT results, etc. And I don't mention split between expected and actual results. I mean lack of unified naming related to whole business configuration (there were different issue types for each of these activities, different story - also extensive too much).
I will get back here to my idea that with systems like Jira - application administrator role is not enough. Either You, as admin, are capable of solution architecture design, or You need solution architect to discuss with key users and make decisions on proper use of business features. Admin will simply follow the request to add workflow, project, Custom Field, architect will question, analyse, justify everything accordingly to governance and to achieve performance.
There is a lot more of course. Assuming that documentation for mentioned project took almost 300 pages, this article is to short to go through every case. But to give You some more insight about important, tricky, or unexpected findings:
- 1800+ projects and 1800+ workflow/Field/permission schemes (little less - 70% of that - notifications schemes and screen schemes, and around 20% of that volume - security schemes) - almost every project had unique set - although after analysing - again - 70%+ had exactly the same configuration, but multiplied.
- Longest workflow - 51 statuses/steps, with 47 allowing transition from all others, in total 10 WF with 40 + (!!!) statuses
- In total - around 300 text multiline fields - about 50% could be cut off based on unified naming conventions, another 30% could be switched to any select/checkbox/radio (and here is the tip - text fields have biggest impact on performance, as they are not indexed, but use full text search, with single ones - does not matter, but at large scale...)
- Natural, organic growth of Custom Fields volume per month at level of 20-30 new fields monthly due to misuse - set of fields was created for each biweekly sprint in one project (field names were referring to Sprint name, so every sprint had the same set of fields/data, but differently named) - that gives new 240-360 CF per year.
- 100+ Jira administrators with full rights to create new objects.
Bottomline - It was a mess to maintain, pain in the back for performance, and definitely not the instance You can use any governance on. By the end of the project - around 70% of findings were transferred into cleaning actions, limiting business config to around:
- 100 Issue types
- 150 active workflows
- 30 Workflow schemes
- 500 Custom Fields
- 20 unified permission schemes based on roles
- 10 notification schemes
- limitation of rights to shared objects creation and management
- and so on
Let's face it - I was not totally happy - I would cut it off more (especially WFs and CFs). But then it is still balancing between governance and performance on the one side, and utility on the other.
Usage Patterns - important but often forgotten
What is often forgotten - is usage patterns. Partly it relates to previous paragraph - way of working within a teams and departments, and use of Jira features (especially shared objects).
There will be a number of things to consider:
- natural and occasional growth of projects/issues
- natural and occasional growth of users volumes
In all cases natural - related to extension of Jira into new business areas, occasional e.g. due to merges, acquisitions etc.
- Business and technical roles mappings
- Related to above user profiles (what is used, how, when, for what reason)
And here again - You need to avoid situations where You loose control over it (100+ admins - remember?). Growths can be anticipated, analysed, and adopted, if only there is a good communication and understanding of Jira's role in business processes (critical or non critical system, and core, enabling, enhancing role - I would say in most of cases it is not critical, but enabling - means - secondary just to critical systems). That means that governance over Jira health and performance is not one-off, neither occasional task, but ongoing process, requiring owner, rules, and enough effort.
Then - usage pattern themselves - they are transferable into roles, schemes, specific rights and so on. It has to follow identity management policies - and even in agile, distributed organisations - need to follow some ground rules, gathered in governance practice. You should keep standards, and base on standards for project roles and technical roles. Exceptions - as per name - are one-off setups for very specific, business wise needs. Let's make not mistake here - none of business mapping is so unique that couldn't be just variable from standardised way of working. If someone states otherwise - usually it is due to some tendency to run micromanagement, or shadowing the responsibilities.
Micromanagement trends usually will result in will to keep projects totally under control of one-two persons, giving them all, including Jira admin rights, to do anything they want, regardless of sense.
"Collective responsibility" trend on the other hand - drives to giving exactly the same rights (often, including Jira admin).
Both results in lack control over changes to specific projects. And then Your Jira holds 10 of them - it is not the issue. However, when it holds 1000... It is.
3 top tips for successful cleaning of Jira
Ending this story I would like to share with you 3 top tips I assume are the most important. And even if You consider them truisms, memorise them, and recall with every Jira cleaning operation:
- Know Your instance - on daily basis, understand patterns, changes, know the reasons and habits of your users and admins
- Re-utilise as much as possible inline with business needs
- Keep ownership of configuration in strong, knowledgeable hands - with tech, and business architecture acumen.
Then You should be rather safe than worry.
