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
So, back in 2019, Tidying Up With Marie Kondo on Netflix was a big deal.
While my wife and I enjoyed watching the show, it was really more out of relief, seeing the featured homes and families and be able to say, "Well, at least we're not that bad!" (But I really do need to get rid of some of these tech t-shirts I have. But what if they all spark joy?)
But I digress. Let's talk about tidying up a Jira cloud instance I was working on earlier this year:
Jira cloud instance with ~400 users
First, let's talk about the elephant in the room: How in the world did it get like this?
Well, this Jira instance had some liberally permissive policies that let anyone create projects. But to be blunt, Atlassian didn't do anyone any favors by making projects with Shared Configurations into a second-class citizen in the Create project screens.
In my work below, I found plenty of instances where somebody created several projects with identically customized workflows and screens, even named similarly. But in Atlassian's efforts to offer pre-made templates of every shape and size, they've made it even harder to find the option to create projects that leverage existing work.
But also - this client let anybody create projects. So yes, that's going to be an issue. Your first step then, let's call it step 0.5:
You don't want to get into this state again. Take some time to find a project that you can call "Company Standard Software Workflow", and maybe a few alternates like, "Company Simple Task Workflow."
Document these workflows. Put them in your Confluence, and list them as the company standard workflows, and note that any customizations will have to be reviewed by the Jira Steering Committee. (This is a real thing that you can set up!) (Yes, this is easier said than done, you will likely have to get "buy-in" and cut through all kinds of bureaucratic corporate red tape. Make sure you get Program Managers and Engineering Managers and QA Managers and Documentation folks all on the same page. This is actually a whole other article.)
But yeah. Policies are good. Then you can remove broad administrator rights. And have standard workflows.
Oh shoot, I almost forgot one more step.
Even though we're going to be super-careful, you're ultimately going to be deleting workflows/screens/issue types/schemes that somebody may miss. So then, MAKE A BACKUP, and know how to restore it somewhere so that you can at least visually see what you may need to re-create. Oh hello sandbox feature!
OK! Let's get to cleaning up.
It turns out that many of these objects and schemes for projects that have been deleted, which means they're not associated, and hence, show in the UI as deletable. Bob Swift's venerable CLI is a huge help, as it has actions that let you delete objects and schemes, and they have a "deleteEnabled" option to ensure it only runs on objects that can be deleted. Using those actions, I was able to cut some of these numbers in half.
This works for:
With a little bit of extra work with Excel, you can also use CLI to clean up unassociated issue type schemes and inactive workflows.
All of the CLI commands I used (and more) are in this separate article: Jira Cleanup with CLI.
Optimizer is your friend. It's clear somebody didn't actually understand what issue types are for, and there was also possible evidence of imports that went awry (issue types named: ABC-1, ABC-2, ABC-3?).
Luckily Optimizer lets you find unused Issue Types and quickly start deleting types with no issues.
WARNING: Before doing this, you want to make sure you can see every issue. The Permission schemes may be in a crazy state, especially with 97 of them. And don't forget about Next-Gen projects.
When you export workflows using the CLI action getWorkflowList and add the option --outputFormat 999, the resulting CSV will include a column with the number of steps in that workflow.
In my case, I found several (like at least 50) workflows with only 1-step. These are not valid. (My suspicion is that these were the result of some kind of import that went wrong.)
Working backwards, you can determine which workflow schemes these workflows are part of, and if they are single-workflow workflow schemes, you can replace these schemes with one that includes a standard workflow that will actually allow issues to be closed.
For any future archiving of projects, first switch them to use these schemes:
After archiving Projects, rinse and repeat (clean out all of the unused schemes that you can.)
So... definitely an improvement. But it took a while. And I omitted a lot of very tedious work I did trying to manually find identical workflows.
Hopefully your cleanup effort won't be quite this onerous.
One last tip: Remember to document your work. It's good to open up the initial CLI listings of various schemes in Excel and use that as a record and history of everything you've cleaned up.
Oh, and while this work was done on Jira Cloud, the techniques (and tools!) will certainly apply to Server as well.