Spring Cleaning for Jira

[Meg Holbrook]

A mighty cackle was let forth through my office at this unexpected @Monique vdB "Mo-ment".

[Heth Siemer]

Initially we weren't sticklers. That's what the problem is... we have insane amounts of redundancy. We've cleaned up about 1K so far ((now that I'm looking at the correct stats haha))

[Meg Holbrook]

@Heth Siemer - 

Woo hoo! Down 1k! Spring cleaning like:

[Heth Siemer]

The Megicorn will poke you with her horn if you don't have a good use case.

@Meg Holbrook @Monique vdB

[Meg Holbrook]

This is me at my desk right now: (PS: How do I make this my face in real life??) I've never been painted like one of your French girls before.

[Monique vdB]

RIP me, I have just died of joy seeing that drawing. 

[Steven F Behnke]

We have 2k+ and it causes serious headache to use the UI. It has other performance implications, but the most impactful is Jira's UI and. For instance, while selecting Columns for a filter, the view only returns ~10 results, maximum. For some fields, it's simply not possible to add them to a query, just because the Columns window won't let you.

I'd like to reduce back to ~500, or at least that's the game plan. There's a lot of garbage or things that simply do not belong.

[Meg Holbrook]

Good luck with this @Steven F Behnke! It's really hard to get users on board with reducing fields they're used to, especially when those fields are involved in reports, workflows, etc. 

I have to say though, that getting that number down is such a relief from an admin perspective.

[Steven Behnke]

@Meg Holbrook, thanks, but mostly our issue stems from users having admin in Jira in the early days of adoption, and creating fields that are useless in Jira, such as 'PREFIX Assignee' to represent their PREFIX Project, numerous 'Part Number' fields of different types, etc.

I'm fine with a lot of fields, I can deal with the config and performance implications, but the usability of the tool is my biggest concern. A lot of places in Jira seem to make the assumption that you will not have a lot of Custom Fields, when in fact I'm dealing with the opposite in my implementation.

I get it, people like fields -- To be frank most customer cannot answer "Why do you need this data" -- They're just making busy work for people. This isn't conclusive, this isn't everyone, but a lot of the fields are useless and not reusable. If they truly offer no value to the company and they are not reusable, they do not belong.

I find that when people say 'we need this' they don't actually know what they need, or want, or how to implement it. To be frank, I don't find Jira administration terribly difficult -- A business process is a business process and Jira is just another cog in that machine.

[Meg Holbrook]

Definitely agree @Steven Behnke. 

I administer a mortgage origination system with tens of thousands of custom fields (most created before there were even certified admins for that system in the Org). Getting users to reduce those fields, even when the system was underperforming, was a nightmare. To this day, we have been unsuccessful in making a dent. 

Fortunately, I had full control over the JIRA implementation and was able to enforce a strict process for adding new fields so that we did not have the same problem. 

[Denis Shestov]

@Daniel Eads _unmonitored account_ many thanks for such useful, must-have material! 

[Fadoua]

That is exactly what I am doing this Sprint, clean up and still lot to do. I started with Custom Fields by running some inner joins to figure out which ones should be removed. I think so far it is going well.

Next will be some useless screens and screen schemes.

Thanks for this great article @Daniel Eads _unmonitored account_!

[Stefan Krooshof]

Thanks, great article. It motivated me to start a similar initiative. 

First, we created a set of guidelines for scheme naming, customfields governance, standards for ordering fields on screens, consolidated workflows and screens to recycle as much as possible, 

Then removed all the unsused schemes, screens, issues, fields and workflows. 

Our Jira is not necessarily faster (hard to say, we have other bottlenecks), yet as a team, WE are ! 

Best idea of the year so far :)

[Ajay Ramachandran]

Need one for bitbucket now!

[Sébastien Lucchini]

Thank you for this good and helpful article.

[Tanya C]

Cleaner for Jira looks perfect.  We have a trial and are working the purchase through the chain.  I can't wait to get it online and start using the delete buttons!  We are also implementing a new set of 'default' schemes and working to remove duplicates and move projects to the defaults.  Going to take a long time with 1700 projects but it'll help in the long run.

We too have a justification 'for the whole of the instance' requirement for new fields now.  But we still have some that were added 'back in the day' that we'll have to work to eliminate.  This is a full time job!

[Fadoua]

@Tanya Cyou can think about me as an "Old Fashion" person. I will not rely 100% on a plugin, I will still run queries to avoid some ugly surprises. Btw I do have the cleaner and yes I like it too.

Cheers,

[Tanya C]

Thought I'd add a follow-up to my comment from May.  I have implemented a project archive and deletion policy and started deleting projects ... as well as the numerous agile boards associated with them.  I have removed approximately 700 projects.  After the first surge of deletions I went 'Cleaner for Jira Crazy'.  Since then I've deleted thousands of schemes, screens and workflows.  I'm now working to nail down a better list of custom fields by finding the old-balls (those very specific to a single project) and work with teams to migrate to a different field or remove unused fields entirely.  Without a routine process for project removal our large scale instance would be slow and 'clunky'.  

Policy:

No activity for 90 days and the project is 'locked' with a global admin read-only permissions scheme.  We use configuration Manager to archive the project.

After 30 more days in lock down the project's issues are exported to CSV and saved in a safe location then the project, including Agile boards, is deleted.  

After each deletion effort we restart the process.

NOTES:

0 Issue Projects:  These don't have 'activity' in Jira's eyes so they are harder to eliminate.  We've started a practice to add a DO NOT DELETE issue for each project.  This lets us know the creation date of the project and can track in-activity should no more issues be created.  You'd be surprised how many groups ask for Projects and never use them.

Jira Service Desks: If a portal is out there users can submit to it masking the inactivity of the project.  These have been harder to find but we're looking for some created JQL to find those without resolved issues over time.  If anyone has a method for this please share it.  I'm certain there are at 50 or more projects in my instance that are what we call JSD Driftwood.

[Walter Buggenhout]

Great update, @Tanya C! Thanks for sharing!

[Rodrigo]

Hi! Is shrinking the project's Field Configuration any good?

Does it affect production performance or reindex performance?

Cheers

[Tanya L Christensen]

@Rodrigo, IMO any time you can trim your field configurations, fields contexts I believe performance is improved.  It's hard to tell with our large data center instance because at the same time we trimmed fields and related schemes we also archived then deleted hundreds of inactive projects.  Our effort did improve re-indexing down from two days to 1 day, 9 hours.  Still a lot of time but we run the index on a node that is 'offline' from our load balancer.  

[Fadoua]

@Rodrigoevery time you add a custom field it gets applied to all projects available within your jira. You may not have it configured on a project but that's how it works. Yes definitely they will make your instance slow.

[Rodrigo]

Thanks @Tanya L Christensen and @Fadoua!

Just shared my experience in optimizing Field Configurations using JMeter! :-)

https://community.atlassian.com/t5/Agile-articles/Cleaning-up-Field-Configurations/ba-p/938412

Cheers!

[Laura Bantug]

This is really great and concise information - thanks so much!

[Tanya L Christensen]

Note: Cleaner for Jira is now called Optimizer for Jira

And its awesome!