Sole Survivor: How Fidelity Investments reduced Jira customizations by 99% | Team '23 | Atlassian

Summary

The speaker from Fidelity shares their journey of consolidating a sprawling Jira instance with thousands of projects and customizations. They detail the process of reducing workflow statuses from 1418 to 12 and custom fields from 2008 to under 100, enhancing performance and usability. The talk covers strategies for managing pushback, leveraging tools like Project Track and Script Runner, and the importance of templates and archiving old projects. It concludes with the satisfaction of a cleaner, more efficient system and the positive feedback from initially resistant users.

Takeaways

• 🕒 The speaker recounts the transition from using multiple tools like RTC, Rally, and Jira to a standardized enterprise instance of Jira in 2009.
• 🔧 There was a significant issue with over-customization in Jira, leading to performance issues and inconsistencies in how teams worked.
• 📊 The company had an extensive list of custom fields and workflow statuses, which were reduced for better standardization and performance.
• 👥 The process involved consolidating numerous Jira administrators into a smaller, more knowledgeable team to manage the enterprise instance effectively.
• 🛠️ The importance of balancing team autonomy with enterprise control was emphasized to ensure consistent processes and standards.
• 🔍 The reduction in custom fields and workflow statuses improved reporting, analytics, and administration, making the system more manageable.
• 🔗 The need for integration with other tools like Jira Align and custom tools was a driving factor for streamlining Jira's configuration.
• 📉 The company faced pushback from teams resistant to change, but eventually, these teams acknowledged the benefits of the streamlined process.
• 📝 The script discusses strategies for reducing custom fields, such as analyzing usage, consolidating similar fields, and removing unused or cloned fields.
• 📉 The company successfully reduced the number of workflow statuses, custom fields, screens, and issue types to create a more streamlined and efficient system.
• 🌐 The push towards cloud migration was another reason to declutter the Jira instance, aiming to avoid carrying unnecessary legacy configurations into the new environment.

Q & A

What was the primary reason for adopting Jira at Fidelity in 2009?

In 2009, Fidelity needed a tool to manage work in a consistent way across the organization as various teams were using different tools like Rally and Jira. Jira quickly became the preferred choice due to its flexibility and the need for an enterprise instance that everyone could use in a similar manner.

Why did Fidelity end up with numerous Jira Administrators and extensive customizations?

Fidelity had a lot of people wanting to use Jira, but with a very small team to manage it. This led to the creation of many Jira Administrators across the enterprise who didn't have all the necessary knowledge, resulting in extensive and inconsistent customizations.

How did the overuse of custom fields impact the company's reporting and data consistency?

The overuse of custom fields, with some being misspelled and others capturing the same data in different formats, made it difficult to report on data or maintain a consistent process across the company, as people were using different fields for the same data.

What were the main reasons for standardizing Jira at Fidelity?

Standardizing Jira was important for improving performance, simplifying reporting and analytics, easing administration, enabling easier integration with other tools, ensuring a consistent process for associates, and enhancing usability by reducing the overwhelming number of fields on screens.

How did Fidelity reduce the number of custom fields from 2008 to under 100?

Fidelity started by identifying and removing fields with low usage, similar names, and fields that were no longer on any screens. They also addressed fields with the same value and those that were cloned unnecessarily. The process involved analysis, engagement with power users and admins, and the use of tools like Script Runner.

What was the strategy for consolidating the 1418 workflow statuses into a more manageable number?

Fidelity streamlined the workflow statuses by standardizing the core statuses and allowing individual projects to select additional statuses they needed. This was achieved with the help of an app called Project Track, which enabled project-level configurations that could influence workflow conditions.

How did Fidelity address the issue of having 3685 screens reduced to 154?

The reduction in screens was part of the ongoing effort to tidy up and standardize the Jira instance. While the script does not provide specific details on this reduction, it implies that a thorough review and consolidation of screens were conducted to ensure they were necessary and not duplicates or obsolete.

What was the initial resistance Fidelity faced when trying to standardize Jira, and how was it overcome?

Initially, there was pushback from teams who felt that standardization would stifle their unique processes and needs. However, after the standardization was implemented and its benefits became apparent, such as improved performance and easier workflows, the previously resistant teams acknowledged the improvements and admitted that the changes were necessary.

How did Fidelity ensure that the standardization process was well-communicated and understood by all stakeholders?

Fidelity used various methods to communicate the changes, including engaging with power users and admins, creating generic fields for miscellaneous data, adding banners on Jira to direct users to a Confluence page with detailed documentation, and renaming or disabling fields that were being decommissioned.

What lessons did Fidelity learn during their Jira standardization journey?

Fidelity learned the importance of starting with low-hanging fruit, limiting the number of Jira admins, putting guard rails in place to prevent new customizations, creating templates for new projects, archiving old projects, and using listeners to clear custom fields on cloning. They also discovered the satisfaction in deleting unnecessary configurations and the value of using apps like Project Track, Script Runner, and JXL.

Outlines

00:00

🔄 Transition to Agile and Jira Implementation

The speaker begins by setting the scene in 2009, discussing the shift towards agile methodologies and the need for a unified tool to manage work processes. Initially, Rational Team Concert (RTC) was used, but it lacked a consistent enterprise process. The adoption of Jira became prevalent due to its preference among the team. However, the rapid growth led to a decentralized approach with numerous Jira Administrators, resulting in extensive customizations and inconsistencies in usage. The speaker highlights the challenges of managing custom fields and workflow statuses, emphasizing the need for standardization to improve performance, reporting, and integration with other tools.

05:02

🛠 Streamlining Jira with Standardization Efforts

Caroline from Ireland, working for Fidelity, shares her experience in managing a large-scale Jira instance with thousands of projects and users. The narrative focuses on the consolidation process, which included reducing the number of workflow statuses, custom fields, workflows, screens, issue types, and other configurations. Despite initial resistance, the standardization led to improved performance, easier reporting, and better data management. The speaker details the strategies employed to reduce the number of custom fields and the importance of engaging with power users and administrators to facilitate the transition.

10:02

🌐 Consolidating Workflows and Custom Fields

The speaker delves into the specifics of how they managed to consolidate thousands of workflows into one standard workflow for all projects, using an app called Project Track to capture project-level configurations that could influence workflow conditions. They also discuss the challenges of dealing with custom fields, including cloning issues and fields with default values that bloat the system's index. Strategies for identifying and eliminating unnecessary fields are outlined, such as analyzing usage, consolidating similar fields, and removing unused or cloned fields.

15:03

📈 Implementing Project Property Customizations

The speaker explains how they achieved a unified workflow across 5,000 projects by leveraging the Project Track app, which enabled project-specific configurations. This approach allowed for a core set of workflow statuses with additional project-specific statuses selected by each team. The integration with Jira Align and other tools required careful management of epic linking and story points. The use of conditions within the workflow to adapt to project configurations is highlighted, showcasing a flexible yet standardized process.

20:03

🗑️ Lessons Learned from Jira Consolidation

The speaker reflects on the lessons learned during the Jira consolidation process, emphasizing the importance of starting with low-hanging fruit and limiting the number of administrators. They discuss the creation of elevated user groups to reduce the need for admins while retaining functionality. The implementation of guardrails to prevent the creation of new customizations is also covered. The speaker shares insights on the use of templates for new projects to prevent the proliferation of unique configurations and the process of archiving old projects to free up system resources.

🚀 Final Reflections and Satisfaction from Cleanup

In the concluding paragraph, the speaker expresses the satisfaction derived from the cleanup efforts, particularly the reduction in system complexity and the positive feedback from users who initially resisted the changes. They highlight the use of apps like Project Track, Script Runner, and JXL in facilitating the cleanup process and invite questions or connections on LinkedIn for further discussion.

Keywords

💡Agile

Agile is a methodology for project management and product development that emphasizes flexibility, collaboration, and customer satisfaction. In the context of the video, Agile is the approach that prompted the need for a tool to manage work processes, leading to the adoption of various tools like RTC, Rally, and Jira.

💡Jira

Jira is a popular project management tool used by software development teams for issue tracking, agile project management, and bug tracking. The video discusses the standardization of Jira across an enterprise to ensure consistency in work processes and to address issues arising from over-customization.

💡Custom Fields

Custom Fields in Jira refer to user-defined fields that capture additional information relevant to the project or task at hand. The script describes an overabundance of custom fields, which led to inconsistencies and inefficiencies, and the subsequent effort to consolidate them for better performance and usability.

💡Workflow Statuses

Workflow Statuses are stages in a project's lifecycle defined within Jira's workflow. The video mentions the consolidation of numerous workflow statuses to a standard set, which was crucial for simplifying Jira's usage and improving reporting capabilities.

💡Performance

In the context of the video, performance refers to the operational efficiency of the Jira instance. It discusses how excessive customizations can negatively impact performance, and how standardization can enhance it by reducing the load on the system's index and database.

💡Reporting and Analytics

Reporting and Analytics involve the collection and interpretation of data to inform decision-making. The script emphasizes the need for standardized processes to facilitate easier reporting and analytics, as inconsistent data capture through custom fields made this challenging.

💡Integration

Integration in this context refers to the ability of Jira to work with other tools and systems. The video describes difficulties in integrating Jira with other tools due to extensive customizations, highlighting the need for a streamlined and standardized setup to enable seamless integration.

💡Usability

Usability is the ease of use and the effectiveness with which a tool can be employed. The script discusses how an overwhelming number of fields and customizations can decrease usability, as it becomes difficult for users to navigate and interact with the system efficiently.

💡Consolidation

Consolidation in the video refers to the process of reducing the number of items, such as custom fields, workflow statuses, and issue types, to a standard set to improve consistency, performance, and manageability within the Jira instance.

💡Archiving Projects

Archiving Projects is the process of moving old or inactive projects into a state where they are no longer accessible for regular use but are preserved for historical or compliance reasons. The script discusses the strategy of archiving projects that have not been used for a certain period to declutter the Jira instance and simplify management.

💡Pushback

Pushback in the video refers to resistance or objections from users and administrators to the changes being implemented, such as the reduction of customizations. It illustrates the challenges in driving standardization and the eventual acceptance once the benefits of the changes become apparent.

Highlights

Transition from using multiple tools to a unified Jira instance for consistency in work processes.

Challenge of managing a large number of Jira administrators with varying levels of knowledge.

Significant reduction of custom fields from 2008 to under 100 for better performance and consistency.

Consolidation of workflow statuses from 1418 to 12 for streamlined reporting and analytics.

Importance of balancing team autonomy with enterprise standards for effective Jira administration.

Performance issues caused by excessive customizations and the benefits of standardization.

Difficulties in system administration due to numerous customizations slowing down the Jira interface.

Integration challenges with other tools due to heavy customization.

The need for a consistent process for associates moving between teams within Jira projects.

Usability issues with an overwhelming number of fields on Jira screens.

The impracticality of exporting data with 2008 custom fields.

Migration plans to Jira Cloud without carrying over unnecessary legacy configurations.

Strategies for reducing custom field count by analyzing usage and consolidating similar fields.

Use of Script Runner to assist in copying custom field values during consolidation.

Implementation of Project Track app to manage project-level configurations for a unified workflow.

Overcoming pushback from teams by demonstrating improved performance and usability post-consolidation.

Approach to gradually reduce the number of Jira administrators to streamline administration.

Creation of elevated user group for performing certain admin tasks without full admin privileges.

Establishment of strict guidelines for new customizations to prevent further bloat.

Use of templates for new projects to prevent the creation of new workflows and screens.

Mandatory archival of unused projects to free up system resources and simplify configurations.

Utilization of listeners to clear custom fields during cloning to prevent unnecessary data propagation.

Introduction of apps like JXL for in-depth data analysis within Jira, enhancing the cleanup process.

Sense of satisfaction derived from successfully reducing Jira's complexity and improving its performance.

Transcripts

foreign

[Music]

good afternoon

we're going to rewind the clock back to

2009. this is about the time when

infidelity everybody started doing agile

and we needed some sort of a tool to

manage our work at the time we used RTC

rational team concert don't know if any

of you heard of it

and it did it did the job okay but we

didn't really have a good enterprise

process for how everybody would do their

work the same way so some people started

using rally and then people started

using jira and we had all different

tools and nobody was doing anything a

consistent way

very quickly it became obvious that jira

seemed to be the preference that people

had so we needed to pull together a team

make sure that we had an Enterprise

instance of jira that everybody could

use and use it in a similar way

the problem was there was a lot of

people who wanted to use jira and we had

a very small team so this resulted in us

having lots of jira Administrators all

around our Enterprise who didn't maybe

have all of the knowledge they needed to

have as how best to administer jira and

this resulted in a lot of customizations

and I mean a lot of customizations I see

some of you nodding so you obviously can

empathize with this situation

so let's take a look at um some of our

custom fields so you can see on here

some custom fields that are related to

Applications so we had 15 20 maybe 30

custom Fields trying to capture either

an application ID an application name

some of them were free texts some of

them were single select drop downs some

of them highlighted in red were even

spelled wrong and how were we ever

supposed to report on our data or have

any sort of a consistent process when

people were using different fields for

the same data so in this instance we

were able to get all of these fields

down to two one free text and one single

select drop down everyone could continue

to work the way they wanted to work but

we had a more consistent process

but why do we care all we've heard about

in all of our Keynotes is we need to let

teams work the way they want to work and

they need to do their own thing they

need to have their own processes

but we also need some sort of control to

make sure we've got standards in place

so getting the balance between these is

really important so the first reason we

care is performance if you've got a

really big instance of jira and you've

got thousands of customizations it will

impact your performance so by

standardizing you can improve your

performance

if you want to do reporting or get

analytics if you have everybody using

similar workflow statuses that's going

to be much easier we had nearly 1500

workflow statuses now I don't know how

many different variations of to-do and

progress done you can have but we had

1418 of them

Administration so any of you here who

are jira administrators know that if

you've got a lot of customizations it's

really really difficult to keep your

system in sync and keep everything up to

scratch our custom Fields page used to

take 10 minutes to load this is before

it was paginated I know it's paginated

now but it took 10 minutes this was

before you even went in and configured

any context

we want to integrate with other tools so

we have jira align we also have some of

our own homegrown tools that we take

jira data out of it was almost

impossible to integrate with some of

these tools with the amount of

customizations that we had

we want to have a consistent process for

our Associates if somebody is working on

a jira project and they move to a new

team it shouldn't feel like they have to

learn it all from scratch they should be

able to have a new to your project and

know exactly how to work it

so that comes down to usability as well

if you've got a screen that has 79

fields on it how usable is that for the

person who's actually doing the work

they're overwhelmed with the amount of

fields that are on the screen

exports

2008 custom Fields is what we had at the

peak every time somebody wanted to

export from jira they got a spreadsheet

with 2008 columns in it plus system

Fields so let's say 2025 and all of that

data was in there all of these columns

despite the fact that they didn't use

the fields

and lastly we want to get to the Cloud

we're hearing about all the really cool

things that lastly and have in cloud and

we want to get there but we're not

bringing almost 15 years of Legacy

configuration and data with us that we

know is not going to be needed in the

future

so I'm Caroline uh you might have

guessed I'm from Ireland I work for

Fidelity and I have been working on a

jira application for about the last five

years we have a geodata center instance

we have 5 000 projects or maybe just shy

of that and about 30 000 users so that

shows you the size of the setup that we

have

what did we consolidate so we've talked

about some of these already fourteen

hundred for 1418 workflow statuses now

we have 12. we had 2008 custom fields we

have a hundred and three we're going to

get to under 100 that has always been

our Target

workflows I'll talk about this later we

had over 2 000 we have one workflow now

everybody uses the same workflow

screens

3685 screens and now we have 154.

there's work to do here because we're

still working on custom Fields but we

will tidy these up further issue types

466 versions of Epic story task book and

subtask how is that possible we had

issue types called watermelon pineapple

orange and grape

now somebody could explain that to me I

would really appreciate it we don't have

them anymore we now have 14 issue types

and roles everything else all of the

other schemes notifications permission

schemes everything was Consolidated down

into less of what we had

people don't like this we got a lot of

pushback why are you trying to control

us this is working the way it is why are

you forcing us to change we're different

we need something different our leaders

don't want this we need to report up

different information than you think

that we need to do this works for us we

don't have time for this you can't force

us to do this I'm sure you've all heard

all of these things when you when you

get pushed back what we've found is

after doing all this work all of these

people who are pushing back are now

coming to us and saying you were right

we didn't understand it's so much easier

now the performance is so much better

we've got better data sorry for being

such a pain is what we get

so I'm going to talk a little bit about

custom Fields this is probably the

biggest one that impacts performance

because all of the custom field data is

loaded into your leucine index which is

load your boards and your search so

reducing the size of your index has a

significant impact on performance so we

started off with custom fields that had

low usage so we did a lot of got a lot

of data from the database you can only

export a thousand rows at a time from

GRS so it's difficult to get the data

from the UI so there are custom fields

that existed that were used on older

projects that those projects didn't even

exist anymore so they didn't have any

usage so we went and looked for it there

was nothing there they were easy we

could get rid of those very quickly

Fields with similar names talked about

that already with our application if

there were Fields with similar names

they were obviously trying to capture

the same data so we Consolidated those

we looked at fields that were the same

type so if we had check boxes we looked

at all checkbox Fields if we had

multi-select drop down we looked at all

of them are there any of these that we

can consolidate together

if they weren't on a screen why do we

have them if they're not on a screen if

nobody can see it there's no point

having it get rid of it

we looked at fields that had all the

same value so it was actually amazing

how many fields all had the same value

it's like what is this giving you if

every value was the exact same why do

you need this field it's never different

you never put in a different value

cloning was a big problem for us so with

all these custom Fields every time you

clone a story or an epic the data gets

cloned from the previous story or epic

and people seem to be like serial

cloners that we have things have cloned

for the last 10 years

fields that were on the screen 10 years

ago are no longer on their screen but

the value keeps getting cloned so it

looks like the field is being used but

it's not being used so that was

something that we really had to look at

in a recent updated jira we got really

good information on the custom field

screen to see the recently used so

that's another data point we use if

they're used a lot but they haven't been

used in a year maybe this is a field we

don't need anymore and one of the

biggest things that we targeted was

custom Fields with default values so if

you have a default value and you have

all 5000 projects and the context isn't

set up correctly every single issue in

every single project gets that default

value and this is all in your index and

it's all in your database

so how did we do it so there's a lot of

analysis that you need to do if you're

removing or consolidating a custom field

because you have to find out if it's

being used is it really being used or is

it just being cloned and who's using it

so once we determine which fields we

were going to work on we would engage

with the power users and the admins to

make sure that they knew we were doing

this so once they were informed they

could talk to their teams

we created some generic or miscellaneous

fields that where people had a specific

need we'd say to them okay we've created

a field called more info or data and you

can put whatever you want in there it's

you know you can use it how you want on

your team but we don't need we didn't

need specific fields for every single

project who wanted to do their own thing

we use script Runner a lot so we copied

all the custom field values when we were

consolidating from one to another we

could not have done this without that

ability in script Runner to copy from

one to the other

then we started trying to make sure that

the customer knew this was happening so

if we were removing a custom field we

added a description to say this is going

to be decommissioned and if it was a

drop down we disabled all the values in

the drop down and just put one value in

that said to be decommissioned so they

knew they couldn't use it their existing

data was still there but they couldn't

use it going forward

and in some cases we actually renamed

the field and put do not use at the end

of the field so this people will come to

us and go why does this field say do not

use

then we'd remove them from the screen so

removing from the screen is very low

risk because it doesn't delete any data

data's still there it's just not on the

screen that's when people would come out

of the woodwork and go where's my field

gone so then we could have a

conversation with them then we'd remove

it from the search so again it's still

there but if they're trying to type it

into jql they can't because it's not in

the search

we added a banner on jira to a

Confluence page so everything we were

doing was documented on this Confluence

page so anyone who wanted more

information could click on the banner

and go see what we were doing and

confluence and lastly we delete the

field

we always coordinated our deletes with a

refresh from our production environment

to our non-production environment so

when we deleted fields we didn't delete

them QA and then production we deleted

them in production and kept them in QA

so QA acted as a backup for us just in

case now thankfully we rarely had to use

it but we just had it as an extra backup

just in case

so that's cost of fears and let's talk

about projects I'm sure a lot of you are

interested to to know how we could

possibly get 5000 projects onto one

workflow this has been a dream of mine

and all of my team for a very very long

time but how can you ever get everybody

to agree on one workflow that the same

process is going to work and it goes

against everything we've heard today

that we need to let teams work the way

they want to

in jira you could have a certain amount

of properties at a project level so you

can have a name a key an avatar a type a

project lead a category a description

but it's very limiting you can't have

very much there so if you need to

categorize your projects differently and

have something at a project level you

can't really do that so we spent a lot

of time looking for a Plugin or an app

that would give us some sort of project

property information so we could capture

data at a project level that we could

then use in a different way

so we had a few different plugins that

we found and then we did our due

diligence and then they weren't going to

be a runner and my head was telling me

this is not the right thing to do this

you know this this vendor isn't replying

to any of our emails so what's going to

happen if something goes wrong but my

heart was telling me I really want to

get this in because I really want to go

with the next step of my plan and then

we came across an app called project

track and I know project tracker here

today they're here and they're at a

stand over there and this has just

changed everything for us so what

project track allowed us to do was to

specify configurations at a project

level and we can then access this data

and use these configurations in post

functions or in workflow conditions to

do something different depending on

what's selected for a particular project

so we have one workflow that has 12

workflow statuses everybody gets to do

in progress done and canceled everyone

gets that there's no choice and after

that each individual project can go in

and select which additional statuses

they want on their project so in this

case testing review and ready are the

statuses that this team wants to use on

top of the out of the box ones in the in

the back end of the workflow we have

conditions set up that look at this

field and say you know if testing is

true show show this transition otherwise

don't so it shows and hides the

transitions based on what's configured

in here

then we took it a step further to add

additional logic because I said we have

some Integrations one of our

Integrations is jira line if we have

teams that are integrated into jira line

they need to put an epic link on their

stories if they don't have an epic for

their stories our data doesn't roll up

into jira line and we we've got black

spots so they have to have an epic link

so if jira line is set to yes once a

story and only a story we don't care if

it's a bug or a task only stories once

it moves into Annie in progress or done

status they have to put in an epic link

similarly if they pick scrum they have

to put in story points once it goes into

an in-progress or a dawn status if it's

kanban they don't have to and the last

thing we did was we put in an option for

making certain Fields required so this

is going to help us get rid of a lot of

the field configurations that we have

today so if a particular particular

project wants to make acceptance

criteria required they can do that if

another project wants to make a

different field required they can do

that too but it's all done project by

project and every team can customize it

how they want to themselves

so I could talk probably all day about

all of the different things that we

Consolidated but were short time and

these are really our two most important

ones workflows and custom fields we

learned a lot of lessons as well when we

were doing this work this has been a

long journey for us and we made a few

mistakes not too many thankfully but we

did learn lots of lessons so the first

one is to start with your low hanging

fruit I mean go into your system there's

things in there already that have a

delete link beside it if delete is there

delete it get rid of it before somebody

starts using it again so delete what you

can already that has no impact start

with that low hanging fruit and then

start with things that are used less

that's always going to be easier to

consolidate or remove limit the number

of admins in your jira instance we had

about 200 admins now we have 50 it's

still way too many the idea is to get to

none apart from our Enterprise team but

what we did was we created a group of

elevated users and this allows people

who used to be admins to do a lot of

what they could do in the past but they

can't go in and do the main

configuration so we've put them on every

board so they can fix people's boards we

have a self-service tool that we built

for creating projects so they can still

create projects through the self-service

tool so this elevated access group has

given people about 90 of what they could

do but they can't create new custom

fields that they can't create new

workflows

you need to put guard rails in place so

limiting the admins is one thing but the

admins that you have need to understand

that certain things they shouldn't be

doing so very early on when we start

this process we said no new custom

Fields no new workflows no new issue

types unless you come to us we have to

approve anything new like that you can

reuse anything that exists but know that

we are going to continue to consolidate

so be careful you don't move on to

something that's not being used a lot

because that's likely going to go

that'll be our low-hanging fruit

we created templates for new projects so

one of the biggest problems we had was

admins going in going you know create

project and selecting

um scrum or kanban and when you do this

it creates a new workflow a new workflow

scheme and you screen a new screen

scheme it creates all these

customizations that are unique to that

project

those worn-off workflows then put gave a

back door where people could add

statuses to their boards non-admins

could add stasis to their board on the

software simplified workflows and they

were the ones creating the 1418 statuses

at least half of them because they were

able to do it on the UI it kind of had

this like back door and create statuses

so by having templates and everyone has

to create a project from a template it

doesn't create new workflows and new

screens it reuses existing ones every

time so nobody is allowed to create a

project by clicking you know new scrum

or new kanban they have to use the link

at the bottom that says create using a

shared configuration and then pick one

of these templates so they're not

creating new customizations

archiving your old project so this is

really important and jira has built-in

archival which is fantastic it didn't

have it when we started this with the

built-in archival you need to make sure

that you migrate people off the schemes

that they're on first because you can't

remove them even if the Project's

archived so if you've got a standard

Enterprise workflow or an Enterprise

screen move them onto that stuff first

and then it'll start to free up some of

those schemes that you you want to be

able to get rid of in our case we

started off looking at projects after

two years of no usage you're going to be

archived mandatory archival that's it it

was before jira had archival so what we

actually do is we take a snapshot of the

database and store it in an S3 bucket

for long-term storage for order purposes

but once a project is archived it is not

coming back into jira it's not coming

back it's gone that's it you know you we

can get to export the data out to you

into a CSV but it's not coming back into

jira we started with two years then we

went to 18 months then we went to 12

months and we landed at six months so at

the start all that pushback I'm going to

need the project I need to go back to my

old stories and see what was in them no

you don't like you don't need to go back

to something two years old and we now

realize they don't even need to go back

to something that's six months old so

getting rid of those old projects starts

to Orphan all these configurations to

make it easier to actually remove them

listeners were really helpful to us for

the cloning problem so we created

listeners that cleared custom fields on

on cloning so that those fields that we

were trying to get rid of that we didn't

know were they really being used or were

they just being used because of cloning

you having listeners clear those out

really helped us to to look at that data

in a different way

there's a lot of apps that we use to try

and help us along the process I

mentioned project track already in terms

of our our workflow I also talked a bit

about script runner for copying the data

from one to the other there's a new app

that we got recently called jxl that has

been really really good for us where it

like overlays Excel on top of jira I

wish we had it about four years ago when

we were in the middle of all our custom

field cleanup but it allows us to like

sum up the data and summarize the data

and get all that Excel functionality to

do the analysis within jira itself

instead of having to export it outside

of GRS so if you haven't seen any of

these apps go take a look at them

project track jxl and script Runner have

been brilliant for us

and lastly there's great satisfaction in

this work I love deleting things like

the thrill I get when I go in and hit

that delete button and see the numbers

come down and my Confluence page that

shows the percentages that we have we

have cleaned up so there is good

satisfaction and especially when those

people who push back come back and say

you were right this is way better we

should have done this way sooner so it's

hard but it's worth it and there's great

satisfaction so hopefully this can give

you all a little bit of a taste of what

it's like to clean up your deer instance

and if you've got any questions I'll be

around afterwards or you can connect

with me on LinkedIn I'm happy to answer

any of your questions thank you