This is the third episode of Idalko Live, a podcast on everything Atlassian. In this episode, Rachel Wright, an entrepreneur, process engineer, and Atlassian Certified Jira administrator, tells us all about cleaning up a Jira instance.
About this episode:
- How to start your clean-up
- Common pitfalls regarding the Jira cleanup process
- The challenges of aligning teams and departments in Jira and how to overcome them
- How long it takes to complete your Jira Clean-up project
- and much more
Not a fan of watching videos? Listen to this podcast episode on:
The Episode Transcript
Manuel: Hello, welcome! I’m Manuel from iDalko and today we’re on our podcast and as a host, for today we have Rachel Wright, and we’ll talk a little bit more about the cleanup for Jira. Rachel!
Rachel: It’s so nice to be your guest, thank you for having me.
Manuel: So the topic of today’s clean-up for Jira. What can we expect today, what are the fields we going to touch on in this case?
Rachel: Well, for me clean up means a lot of different things. It means cleaning up schemes and settings that you no longer need. And it means making things easier for your administrators and your users.
And one example of that is cleaning up or shortening very long workflows. So there are lots of things you can do in Jira to clean up and make life easier for everyone.
Manuel: So probably a typical one is that Atlassian at a long time the land and expand strategy, which they now have stopped with. Meaning that in many companies, Jira started in a little corner, somewhere expanded, and after 3 years all of a sudden they realize they don’t get any decent reports out of it, they don’t manage correctly, and they have a certain amount of flaws. And like some customers have 950 custom fields and so on.
So that’s more or less what we are talking about, what you mean by clean up? What are the typical points you would assess going through a cleanup, where do you start in fact?
Rachel: Well, first really is to think about what problems are trying to solve. If your incense is brand new and nice and shiny and you haven’t over-customized it, I like to tell people: think about the end, think about what reporting needs you have before you start building anything at all. Right?
That’s the goal the way you should Implement new things in Jira is to think about how you’re going to report on those things. So that’s one side of it. But so many of us, like you said, have older instances that have been around for years. They probably started sitting on a server underneath somebody’s desk and then more groups started using it, more administrators started being given administrator permissions and everybody just started creating everything.
And so many of us have those kinds of Jira instances and for us, we really need to assess what we have, so we can determine what is a default Jira setting, what is something that’s been created custom, and what is still needed. And then hopefully get rid of the stuff that’s really not really serving you, helping you report, and helping you keep your instance running quickly.
Manuel: What are the typical kind of problems people encounter that have a cluttered Jira or a wrongly set up Jira? What are the most common issues they have?
Rachel: Lost of things! It could be just very hard for your administrators to manage because you’re scrolling through so many settings. It could be slower, run slower, load slower than it needs to because there’s just so much that has to load on a page. And then for your end-users.
I’ll give you an example. I worked with a Jira instance once that had hundreds of issue types. And every time a new issue was created, the user had to scroll through hundreds of them. They weren’t even alphabetical. So this is just hard on your user to make them choose the right issue type.
Most of the time they just got frustrated, they just choose the first one that kind of made sense. And when users aren’t making good selections, your data suffers and your reporting suffers. So this company could not get a good idea of what kinds of issues they had in their application, because there were hundreds, and people were just picking whatever.
Manuel: So the impact on the business is then one time that you’re paying money to have an instance and everybody puts time and work into it and a lot of data, but you ain’t get nothing back!
Rachel: And that’s the goal is to understand what you’re working, on where that work is, and how the company’s operating strategically. And if you’re just putting junk data in, you’re going to get junk data out and you’re not going to be able to realize all the benefits of Jira, when it’s not well configured and smartly set up from the beginning.
Manuel: In that case, you said we would start from reporting and work backward then. What you need at the end, what’s the results you’re expecting from it. So and reverse-engineer everything through it. But that means the company if it’s a larger company, it’s is several divisions.
First part would be the political one. Everybody needs to be in the new settings. I had many discussions with customers that are almost fighting over the fact that they have “success”, “done”, “fixed” and 10 other words to say the same.
We discussed the part with how the issues occur, too many custom fields, too long workflows, building up the screens, etc… Server reports that take too much time, etc. But to get a consensus, you need to have everybody within the company agree because every division or every team has his own way of working and wishes to keep it so how will you address that part?
Rachel: There’s always 2 challenges, right? There’s a technical challenge of what can Jira do, how does Jira work. And that challenges usually pretty easy to solve. The second Challenge is always cultural, you know. How do you get everyone in your organization to work in a similar way? Different departments and different teams have different ways of working, different information they’re interested in.
So I like to have everyone make a list of what they want Jira to do for their team, what they want to get out of Jira, and what kind of information and questions they want Jira to answer for them.
So for example, you know the legal team might want to know how many open contracts do we have right now. The development team might want to know how many bugs did mark this month. I have them all list out, all of these questions that they want Jira to answer for them. And once we can show them that yes Jira can definitely get all of this information for you and more, they’re more likely to be interested in maybe changing the Jira configuration or potentially changing their behavior in order to get that information.
One example is one team wanted their problems to be called “bugs” and another team wanted their problems to be called “defects”. Well, that slight terminology difference makes it harder to report on problems. So we can just get those two teams to use the same terminology, that’s a huge win and it makes the configuration much simpler in Jira.
Manuel: I can imagine it’s not, as you said, not always that easy. Just to get those aligned, what you called, you have some experience in doing those kinds of cleanups that’s the reason you’re in this podcast because you’re the kind of an authority on that part. So if you would consider how much time, throughput time, does it take to have a kind of a cleanup project done?
Rachel: Well, it depends on the extent of the cleanup. The first thing you need to do is really audit what you have and understand how far you have strayed from the Jira default and that is going to dictate how much time you need to spend on certain activities. One activity might just be getting buy-in from stakeholders that yes, this is something that we need to do, and cleaning up Jira will really help our organization.
And then the other part is just pointing a clicking in Jira, figuring out what schemes you can delete, figuring out what’s not needed anymore, figuring out what you can combine. So really it just depends on how far you’ve gone down that customization road as to how long it’s going to take you to clean it up.
Manuel: In fact by starting with a wrongly set up Jira, it costs heaps of money to the company in several ways. First, the fact you don’t get reporting on which you can lead your business to the results. You want or deficiency you want. Secondly, you need to spend time equals, most of the time, money to redress everything to the shape it should have been in the first place. So if you would have any advice on this part, what would it be?
Rachel: Well, for those of us that are lucky enough to start with a brand new, fresh, clean, up-to-date Jira instance, I tell people always think before you click in Jira, try to lay out what you’re trying to do on paper first.
The first thing you do should not be just to go in and start creating custom elements. But of course, that’s for the people with a nice new Jira instance.
Most of us have a bunch of stuff that we have to clean up and for them, I would say, first be intimately familiar with your customizations. You know, what in your application is specific to your company and what came with Jira. And maybe what was added by an app that you installed. The first thing is to really understand what you’re dealing with. And then you’ll be able to figure out where you can make improvements.
Now there’s one positive part to having a terribly configured Jira instance, your admins will learn a ton! As a matter of fact, that’s how I learned myself, I had one of the worst configurations you can think of, and I had to learn and understand, you know, what did we do? Why did we do it? And what impact has it had before I could kind of reverse engineer it and that was very very valuable from an administrative protective.
Manuel: So the thing is, there’s not a kind of a push of the button clean up that can be done because every setup is different, every culture is different. So it’s not that there is a template that says: here you have it all.
Rachel: Right, right, and there’s an order that you have to remove things. And also some things are easier to remove than others. So for example, let’s talk about a permission or notification scheme. Those are really easy to remove. If you go into the admin page in Jira where those things live, you can see which aren’t associated with any projects and you can simply click the delete button and if it’s not associated with anything, it doesn’t hurt anything. It’s not being used, you don’t need it, you don’t need to keep it around.
But there are other settings that are harder. For example, you can’t get rid of a workflow if a workload scheme is using it. So there is definitely a top-down approach or which changes make sense to make when.
Manuel: Are there any specific tools, because let’s say every the human race is intended to be lazy by nature, and then the first thing people will ask is “is there any tool which we can use with do everything and have an idea of what I have to do and what have to clean”. If they’s, like you said, associations with a type of projects that we have, unused fields, etc. Is there anything specific in the market that can help already to prepare the kind of assessment?
Rachel: Yes, definitely. There are apps in the Atlassian Marketplace that can help you do your analysis. But no matter how good an app is, you’re still going to need a human to decide what is the value of this scheme or the setting, or this custom-built at my organization?
So yeah, I think you can definitely start with a helper app, but there’s still going to have to be your admin team, looking at the results of what was found in determining what needs to go and what needs to stay. I really think a human has to do that analysis. Which one of those apps in the market can help you help the human in question to make the decisions. There’s a lot of great apps out there by a lot of different vendors.
But in addition to apps in the marketplace, you can also write your own scripts. You can use an app that makes it easier to write your own scripts.
And another thing, sometimes when people are removing custom fields, for example, they want to keep the data in that field but not the field itself. You can use apps that help you move that data from one field to another. So for example, a post function in a workflow can be used to move data from one field to a more generic field for safekeeping.
Manuel: Okay, cleaning up does not mean lose?
Rachel: Absolutely, and you need to decide what data is important to retain. Can you delete data at all, maybe your compliance and security standards at your company say that you can’t delete this information, You need to keep it for historical and legal purposes, or maybe you only need to keep it for so many years. Or maybe you can export and keep it separately. There’s a lot of potential things that you can do with that data, but it doesn’t necessarily mean delete.
Manuel: So, some categories of companies need to keep it for 10 years, while others have other rules to apply to because they’re in another vertical of the market.
Rachel: Right, as a matter of fact, I worked for a company that had the opposite requirements, that when they were done with a certain project with a certain client, they deleted that data immediately. So I’ve seen both directions. It just really makes.. it’s different for every organization, every industry, and then sometimes even different countries have different date residency retain and backup regulations they have to follow.
Manuel: Okay, so if you would address the need that there would be for those companies, it would be, if I resume a little bit, you need to get to things we talked about. That means we had some examples where a company had about 80 users and 32 admins! So it means those people change and then they’re surprised that sometimes it goes down. So first of all, you need captains on your ship and preferably they talk to one another during their shift. So they decide what can be done and not be done in their Jira and so on. So part of it, or not only being… having the census but also have some discipline on the naming and the workflows in the world to do it. That’s the need they would have.
Rachel: Absolutely! I recommend that companies have somewhere between 2 to 5 administrators, even if they have really large Jira instances. 2, because you want a backup, right? You don’t want just one person with the ability to do everything. They get backlogged, they go on vacation, nothing happens. So at least 2.
But after 5, it’s very hard for those administrators to talk to each other, to make their changes known to the group and so you don’t make a change that a fellow administrator is working on or you step over their feet or you undo something that they’re trying to accomplish. You know 5 is kind of a, I think, a good round number. The more you have, the harder it is to keep track of what you’re doing.
And I encourage that administrative group to track their changes. So Jira has an audit log, as you know, and the audit log tells you, you know, what change was made, who made it and, when the timestamp. But what the audit log doesn’t do, is it doesn’t tell you why you made that change, how you made it, and who requested it. So I like to have Jira administrators create a project in Jira to track their configuration changes. So their fellow admins know what’s going on and their users get a heads up, too.
Manuel: So in the service portal for example or in the Jira itself, you make it kind of a service catalog to what I need a new field and first compare, why do you need it and so on and so on, you have to go to all your reasons, that’s a very good idea to streamline that process.
If you would just, out of your gut feeling, if you would say out of your experience how many Jiras are really perfectly installed by the letter of using out of the box as much as it can, minimum custom fields, and so on?
Rachel: I’ve seen very few and you know, it’s exciting you get new software, the first thing you want to do as an administrator is to go in there and customize everything and change the colors and change the schemes and it’s hard for people to just step back, and say wait a minute, let’s think about this! Because Jira is so flexible and customizable and that’s a pro and a con, right? It’s great that you can make Jira do absolutely what you want it to do, But you need to be careful about what you’re asking it to do.
Manuel: Exactly! So Jira can do almost everything and it’s at the same time a pitfall because it’s so customizable it can go either way. So in this case, it is how you call it, a kind of thing you need to take up upfront before starting with it. You can make it as simple as you can but you can make it so complex that nobody finds what they’re looking for. So there is nothing tailor-made that we can use. Just everybody needs to reflect a little bit on the usage of it.
But if you have symptoms that you don’t have your reports, any other symptoms like where the reports are, cause most of the time it’s very difficult to pull out because there is no consistency, anything else?
Rachel: Well, just differences between how the project behaves. I’ll give you a horror example. I worked with one company that had 24 different projects just for development. So why were there 24 different projects? There wasn’t a good reason. It was just that every time there was a new company initiative or something big the team was working on, they just created a new Jira project. So what happened was different projects would have different schemes, different terminology, and you get into that cycle where now one project doesn’t operate the same as the other project and now they can’t bring those two projects together for reporting.
So what I recommend is instead of just creating projects whenever you feel like you need them, define when you’re going to have a new project, right? From a Jira perspective and from a company perspective, when is a new project warranted, and when should you just be tracking the work in the team’s general project. So that’s one.
Two, I recommend that you create project templates. So similar projects act similarly. For example, all the dev projects are going to function in this way, you know, we’re going to use this terminology, we’re going to use these settings. All the task type projects, they have their set of settings, and then all the support projects, they have their set of settings too. And with those 3 use cases, you can probably support every team in your organization.
The last thing you want to do is customize every project that you make. I made that mistake, people would come to me and say hey, I need a new Jira project and we’d sit down and figure out all the customizations that they could make all the terminology they wanted to use and it just created a huge mess of unneeded settings and schemes.
I should have just said which one of these three templates “development” “support” or “task” should you start with. And then later after they’ve used it for a while, if there’s a business need to customize something, then we’ll have that conversation.
Manuel: That’s indeed a very interesting point to customize, NO, but standardize, YES! In his case, nobody can come up with his creativity to go the whole way while everything is already invented and he’s ready just some as said bug or defect, a kind of discussions that can be can be avoided.
In case you have too much of that clutter going on, we also have some examples of the practical side, and you’re probably familiar with it, is that a lot of users start to complain that their instance is very slow while they only have like 500 users on a quite powerful virtual machine, the network is operating perfectly, but the server is slow. Classic, you know!
And then you start looking and well the server responses extremely fast. So there’s no issue. And we have the same customer that has 15000 users on one single instance and after some tweaking, it works perfectly! But tweaking where?
Well, it was most of the time, in many cases, it’s the front-end. Because if you have so many boards to build up and so many types and issues and so on, it’s your computer or your laptop at home that is slow. We’ve done a test on i3 i5 and i7 and the difference was between 2.1 seconds for a thousand issues Kanban board and 21 seconds on the slowest, and the server responded within milliseconds on the query. So that’s more or less what clean-up does also in that part. The fewer issues you will have, the more streamlined, I think.
Rachel: It’s never really about how many users or issues, is it?
Manuel: Yeah, exactly! I think we’re gone through most of it, that’s my feeling. So from the report, that’s the first thing everybody needs to think about, what do I want to get out of it? And then go back all the stages up and how to standardize the Jira as much as possible to get everybody in your company aligned on the naming convention of everything.
And also what’s mainly forgotten is that even if the administrators have been talking amongst another and they have to come to an agreement and they had the team leaders into it, they just forgot one part, they never told the end-users how it works. So for those who listen to the podcast, it’s just some advice, please also inform your end-users on how the naming convention works, what are the definitions and probably you even have created the perfect Wiki page where they can find back all the naming conventions you have. So the definitions are the same throughout the company.
If one guy works on a project in another department, with a change from one department to another department, he will have no time required to adapt. So there’s easy flexibility to cross-company use your Jira because you have standardized as much as you can on everything. That’s more or less, I would resume it if you have anything to add Rachel?
Rachel: Just that I think as a Jira administrator, sometimes you’re going to need to say NO. And it’s hard to say no especially if it’s your boss is asking for customization, but every time somebody asks for something, you need to think about “what is the impact to my instance if I make this change today” and “what might the impact be in 5 years”.
So when somebody comes to me, they want a very very specific implementation like they say, I need a new issue type, or I need a new status or I need a new custom field, that’s a clue to me that I need to dig a little deeper and ask some questions and figure out what that user really trying to do. Because sometimes the implementation they asked for isn’t really the best way to achieve their goal.
Manuel: Reminds me of a time when I asked to make some swag and the board says no!
Rachel: Just say no, sometimes you have to say no.
Manuel: True. It’s very difficult when people ask you a question but as we cannot do good for everybody, that’s the part. It’d always be a compromise, one way or the other, to make and everybody needs to be aware and that’s also part of the education towards your end-users. We can do a lot with Jira, but if you want to be able to get out a lot, we need to standardize and we need to get everything in order and we all have to have the same discipline to use it. In that case, we will have one of the most powerful tools on earth to collaborate together.
Thank you very much, I think we came at the end of this podcast. I hope for our listeners there are some interesting topics that have been touched. If anybody has questions, you can always inform us on how you like it, and any topics you wish for the future. Thank you very much, Rachel. Do you have anything to add before we close this podcast?
Rachel: There’s a ton of information, articles, worksheets, downloads on my website, jirastrategy.com, and you can use those to help you audit your own Jira instance and make those small but strategic cleanup items that will really help your instant overtime.
Manuel: I wish you a great day and a million thanks for being our guest for this episode.
Rachel: Thank you!
