You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
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:
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:
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:
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:
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:
In all cases natural - related to extension of Jira into new business areas, occasional e.g. due to merges, acquisitions etc.
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:
Then You should be rather safe than worry.