Jira Admin Mistakes | Rachel Wright | Skillshare
Play Speed
  • 0.5x
  • 1x (Normal)
  • 1.25x
  • 1.5x
  • 2x
21 Lessons (38m)
    • 1. Introduction

      0:48
    • 2. Knowledge

      1:40
    • 3. Ownership

      3:07
    • 4. Test Environment

      2:21
    • 5. Duplicates

      2:31
    • 6. Resolved vs Closed

      1:41
    • 7. Workflow

      1:34
    • 8. Bulk Changes

      2:16
    • 9. Announcement Banner

      1:07
    • 10. External Users

      1:56
    • 11. External Email

      0:59
    • 12. Application Access

      1:26
    • 13. Project Naming

      0:40
    • 14. Issue Types

      1:17
    • 15. Resolutions

      1:47
    • 16. Proper Field Types

      1:19
    • 17. Hidden Projects

      0:49
    • 18. Clean Up

      3:08
    • 19. Multiple Instances

      2:10
    • 20. User Management

      2:25
    • 21. Standards

      2:57

About This Class

Did you hear about the company with 132 Jira administrators?  How about the company plagued with 134 Issue Types?  Have you ever accidentally broken workflows and everyone’s filters?  Join Rachel Wright as she recounts the top 20 Jira admin mistakes she’s made and seen.  Hopefully you can avoid these mistakes and keep your application out of the Jira swamp!

This course is for Jira administrators, but even if you’re not an admin, you can take this information back to your admin team.

Transcripts

1. Introduction: Hi. I'm Rachel, right. Certify Jiro, Administrator and author of The Dearest Strategy Admin Workbook. Welcome to the dear Admin Mistakes presentation. I've been traveling and sharing my mistakes, but I can't be everywhere. And time zones are always a challenge. That's why I've decided to record my stories and make them available online so more people could hear them. I made my stories into 20 individual short videos and after each video are a couple questions to help you continue the conversation. I hope youll discuss these mistakes with your colleagues so you can either fix them or prevent them from happening in the first place. 2. Knowledge: I'd like to tell you about the day I became Ajira application administrator. I had no admin experience, no training, no certification, really know nothing. I was simply an excited and user, but my friend made me a dear administrator, and off I went. I didn't know what schemes were, but I said, Hey, let's build a new project. How hard could it be? And I just followed a model from an existing project. But months later, I realized the model I had followed was built all wrong, and I had copied the mistakes of others and added to the overall mass. So instead, I recommend you create a strong 2 to 5 person admin team who is responsible for new project configuration, customization, user access and daily application management, and avoid giving admin access to excited and users. And random five year olds like the one pictured also clearly defined the application administrator's responsibilities at your company. You need standards and policies for how gear should be used and administered. And finally, why not have each of your admin is prepare for and take the gear certification exam, so the study time alone will be valuable and make them better. Add Mons 3. Ownership: this screenshot shows absolute ridiculousness. I wish the screenshot was fake at one company. Anyone who asked for application admin access got it. And at a company of about 1000 users, there were 100 and 32 ad mons. Now that's 127. Do many. With this set up, the admin is made Any change they wanted and their changes weren't planned, logged or communicated with the rest of the admin team. They're changes had negative impacts on projects and the application as a whole. They did all sorts of crazy things. They duplicated schemes multiple times. They duplicated custom fields. They misspelled custom fields. They installed add ons and never uninstalled them when they weren't used, and the stability and usability of the application degraded every day. I remember that a complex query or a re index could bring the entire application down now at another company, No one on the application at all. Ownership passed from team to team, but each team was always busy managing other applications, so Jared didn't get the attention it needed. Instead decide who's responsible for the application and answer the following questions. Who will make initial and ongoing configuration changes and who will maintain the application. And if you have to, your server, who will perform the upgrades and who will ensure application, server database and network stability. Next, determine the number of administrators needed to properly support the application. I recommend you set both of minimum and a maximum number of admissions, and you can determine that range by a number of factors. You could look at user account, project count, frequency of user requests or even how aggressive your routine maintenance schedule. This now having too few administrators leaves your application UN supported, especially during holiday breaks, emergency events or when other company priorities arise. But having too many administrators results in conflicting changes or modifications inconsistent with your overall application strategy. So here's a tip. Avoid having one team managed all the applications at your company. If that team has many gaps to maintain, will gear get the attention it deserves? And do the admits for the other APS really understand the specifics of Deer administration ? Instead, I suggest you form a dedicated team of ad mons who actually like and care about the app 4. Test Environment: this screenshot shows an easy way to visually distinguish your test environment from production, and you can do this in a number of ways. You can use the built in announcement banner. You could change the display name of the application. You can change the logo or the color scheme or use a unique you Earl. Now My mistake is when I was given admin access, I should have insisted that we set up a test environment. We simply didn't have one. I could have set up a local server instance or even a cloud free trial from my personal experimentation. And I should have imported sample production data and configurations so I could see how my changes worked with riel scenarios. And finally, I should have requested read Onley database access rather than just guessing about how the data was stored and structured. No, I recommend you set up read only database access for your entire admin team. But do note this gives users the ability to view protected data so it could violate your company's security policy. My personal feeling is, if you can't trust your admin team with your data, you have other problems to work out So instead of repeating my mistake, if you don't already have a test environment set one up now that's your homework. It could be a server. Instance a cloud instance or even a local instance on your personal computer. Use this instance to always test major changes. Large imports, upgrades, plug in installations, proof of concepts and cleanup activities before you do them in production. And make sure the resource is powering your test environment. Match your production environment as much as possible. Also make sure that the software version and the configuration are an exact copy of production. And finally, I recommend you disable email in the test environment to avoid notifying end users with duplicate or fake data. 5. Duplicates: When I made my first year of project, I made a lot of mistakes. For example, I created four new duplicate issue types. So, for example, I created Project, name, Task and project named Bug when the generic task and bug type already existed. So in this screenshot example, three of the issue types are really just duplicates of bug. And ideally, you would have just one issue type to indicate a software error. Instead, one company had nine on that same company had 22 issue types with the word task in them. So the more issue types you have, the harder your application becomes To manage a long issue type list means a longer process to move issues or associate them with the different workflow. And at another company roles were utilized incorrectly. So instead of leveraging the Default users role, which is already part of every project, additional duplicate user roles were created and then named for specific projects. So in addition to users, there were also Project One users project to users. This is not needed to make it worse. Default users were added to all of these custom duplicate roles, so when new projects were created, administrators would have to manually remove all those bogus users where they didn't apply . And instead of a tidy list of five rolls, each project now had 20 and the project level of men's were always confused by what the's before. And I always told them, Sorry, please ignore them. They don't even apply to your project. So instead, whether it's an issue, tight accustomed field or roll don't create duplicates and make sure issue type names are generic enough so they could be used by multiple projects and finally regularly audit your existing list of issue types, and if you discover duplicates, remove them by migrating issues to other types. 6. Resolved vs Closed: you can see in the screenshot that the default workflow contains both the resolved and closed statuses for quite some time. I didn't understand the difference between the two, and users didn't understand the difference either. This led to issues being considered done in either status. There was no way to report the total work done without manually adding counts from the two statuses together and issues languished in the resolve status forever. I was gonna leave this mistake out, but I just saw another company do the exact same thing they were using close to indicate. Issues that they didn't do anything for and resolved indicate issues where they did make a fix. And you and I know a resolution Value is the best way to explain how or why something is closed, not a status. So instead, there should only be one status where it's clear to everyone that no additional effort is needed and the standard close status or the business project friendly, done status is sufficient. No need toe ADM. Or status is that mean closed? And if you're going to use the resolve status, teach your users the difference between it and closed at your company and if for some reason you cannot get users to distinguish between the two, rename it or stop using it. 7. Workflow: the screenshot shows an asset management workflow in diagram or visual mode. So I once used the visual Moto edit a status. I thought this change was on Lee going to apply to that one workflow, but instead I changed the name of the entire status in all of the era. So users alerted me to the problem because I had broken all of their filters and work flows . Secondly, I thought, Gee, era treated transitions to the close status. Specially, I thought, There's gotta be logic in the background, making close the final step in a workflow clothes must be special. I thought a status change would automatically trigger that issue. Updated line item. But no, I was wrong. So instead of making these two workflow mistakes, don't change status names in visual mode unless you're really trying to change them in all of Jura. And then Jura has no special regard for that status. Name closed. It's just to stab us like any other. So when you create a new workflow transition, a default post function is automatically added. But as you can see, it reads, fire a generic event that can be processed by the listeners. You want to change that to an issue closed event. If you want a notification sent for that action, 8. Bulk Changes: the screenshot shows the default types when linking one issue to another, and here comes with about six. But at one company, the list of link types grew to 20 different options. So to fix it, I surveyed what options were available, and I removed the unused, outdated or duplicate ones pretty easy. Right gear handled the migration automatically updated any issues associated with these old types, and I thought everything was great. But here's where this went wrong. My action changed the updated date for a large amount of old issues and an internal app was using the rest A p I and they were using the updated date toe limit the number of issues in their own application. So my change caused an increase in the scope of their queries, their queries timed out and their app stop functioning. That was a bad day. So instead, don't create extra link types that you don't need. And also it's really important to know exactly what any APS using the rest AP are doing. And that way you can consider them when making global changes. Also, had I tested this change in a Q a environment first, I could have seen how it would impact other applications. Now I recommend you always test the impact of any clean of activities in your test environment, and here's the way I handle it. After any cleanup action, I manually verify the results. Then I run the Integrity Checker, especially if I've made any changes to work flows. Next, I run all the system health tools, and I reviewed the application logs for heirs that weren't there. Yesterday after I check with every user who's got an app using the rest a p I. And finally I'm ready to respond to any resulting user trouble reports. You can't always plan for everything. 9. Announcement Banner: One day while I was editing the announcement banner, my cat jumped onto my keyboard and he submitted half written code. Now he's submitted her edited your issues in the past, but his careless Paul placement that day really caused a problem. All the end user and admin pages failed surrender content, and I had to stop the application, remove announcement banner records in the database and restart Ghira Now. Luckily, this happened in a development instance where I was the only user and the only human inconvenienced. But the cat and I have since had a chat about his work performance. So instead always test your code outside of Jura and be sure to close all markup tags. And if pages failed to render, you got to remove that Banner co from the database. Also, don't write your code directly in the announcement banner box, right it somewhere else and paste it in 10. External Users: This chart shows a simple set up for grouping external users. So now or in the future, you'll likely need to let it external user log into your app. Maybe it's a temporary contractor and at last in technician or a consultant for an audit or compliance activity. Regardless of the scenario, you should prepare for this before you have the actual need. So consider these simple use cases to external users from one vendor need access to a certain project. And three external users from a different vendor need access to a different project. So these air riel examples from a company that was unprepared for the possibility of external users, and they didn't properly plan for these scenarios at all. Instead, a user with access to one juror project had access to all the others as well. And even worse, any new Jiri user was also made a confluence user. So this meant that any temporary employees had access to all internal company information, proprietary documentation and plans for the future in both applications, and that's not always desired. So instead, try not to couple user access and try to think of ways to determine which is an external user and which is an internal user. And I always make sure that external users have a clear end date when their access should be removed. And here's an easy way to manage this. You can create a new gear issue at the time they're hired to remind the team to perform the removal at a future date. 11. External Email: this screenshot shows fake data, but it's based on a real experience. At one company, a former employee contacted me to complain about Jiro data being sent to his personal gmail dot com email address. After this, I discovered that data was also being sent to hundreds of other past or present users. They had external email addresses in the deer database and were not made inactive when they left the company. So instead, all users should be set up with the company provided email address. Do you really want company? Jiro Data sent to GMO That com email address is, of course, that external email addresses allow sensitive and proprietary information toe, leave your company's servers and be retrieved insecurely elsewhere. 12. Application Access: if you use more than one at lasting an application, it's tempting to give all users access to all applications. But consider how applications may be used in the future and the impact of that decision on user accounts, licensing and auditing or compliance at one company, Dear and Confluence both started out as I t only tools. So to save a step in account creation, any user that attempted log in was automatically added to the General Jiri Users Group. And compliments was set up to allow access to anyone in the GOP users group to now. This work for a while. But then non i t team started using confluence a swell, and there was no way to separate gear users from confluence users. The license usage appeared equal for both applications, and at the same time our auditors started asking questions about our access process. I had a decouple the apse, and it was tedious and manual now. Ultimately, we learned the rial confluence user account was only 25% of the jeering, his account and uncouple ing. The applications made the auditors happy 13. Project Naming: at one company, One project had a 13 character key. Now long he is allowed injera, but it makes little sense to make end users type something long. Instead, a best practice is to make the project's name similar to the project key. That way, users can communicate using either the name or the key, and project name should be descriptive. So the user knows what kind of issues to report there and finally make the project key as short in length as possible. 14. Issue Types: This is a screenshot of utter ridiculousness. Look how long the select box scrolls So how many different issue types could accompany possibly need? Well, the company in this screenshot had 100 and 34 and it wasn't because they were actually needed. But because new types and skiing's were created for every juror project. Another mistake. There were a few projects that use the default issue type scheme, which contains every available issue type, so reporters and that project were overwhelmed when creating a new issue. They had to wade through over 100 available selections, and the choices aren't even listed alphabetically, so Project leads couldn't easily report on or segment the issues their teams were addressing. Instead, don't create issue types you don't really need. Make the type names generic enough so they can be used by multiple projects and then don't assign the default scheme if it contains a lot of issue types 15. Resolutions: this screenshot shows a common mistake. The status is closed, but the resolution is unset. It reads unresolved. So what? One company? There were 34 resolution choices, which included specific selections like Rejected by the security team or rejected by Bob. And many of the selections were really just duplicates of each other, and some were invalid. My favorite example is in progress. So how could an issue that's closed also be in progress? Doesn't make sense at another company resolutions weren't set by work flows at all, and that's the condition in this screenshot. So when this happens, users see all issues, even the ones they've already completed when they used the assigned to me dashboard gadget because from jeers perspective unresolved issues are not completed. The resolution can't be no. So instead, make sure a resolution is being set or selected as part of the workflow. And ideally, you'd show a transition screen and let the user select the correct resolution value. But if that's not possible, you can set a resolution in the background with a workflow transition. Now the resolution is not an easily creditable field. If you have the condition in this screenshot, you have to fix issues with a temporary workflow transition or use a plug in like script runner 16. Proper Field Types: the screenshot shows an example of a field created with the wrong type. The field, called date, was created as a text field instead of a date type field. Now this makes information impossible to query or sort. Please avoid this instead, when you create a new field, be sure to select the best type for the use, because once a field type is chosen, it cannot be changed to fix it. You'll need to create a new custom field my great any data from the original field to the new field, remove the original field and then update the screens to show the new field. It's much easier just to pick the correct field type in the beginning. Also, check boxes and radio buttons air commonly confused. So here's the difference. Use a check box if the user can choose multiple selections so the user can choose none one or several options for one question, but use a radio button. If the user must choose only one option 17. Hidden Projects: this screenshot shows a good way to hide a project and a bad way. So one application administrator decided to hide projects by giving the browse permission toe on Lee, his user name. And when he left the company, so did the knowledge that these projects even existed. I only found out about these projects during a database examination. So that's another good reason for your admin team to have read only database access. Instead, make sure your admin team is thinking about the future and the big picture. You want to avoid hard coating your personal account in configuration settings. 18. Clean Up: at one company. No cleanup efforts had ever taken place. There was no customization or maintenance strategy, and custom is ations were added, but none were ever removed. Now few of us are lucky to start out with a fresh and clean gear installation, and even fewer of us will make no configuration mistakes along the way. But that's okay. If your application is already a mess, there are steps you can take to clean it up. So to clean up Ajira Swamp, the very first step is to survey the schemes and settings and get rid of old and unused items. Next, delete any an active work flows unused custom fields or disassociated schemes, then examined all the projects to determine which are still active and which have no recent activity. The easiest way to do this is through the database, but if you don't have database access, you can look at a Project summary page and look at the recent activity. And when you find old projects, make them read only and get rid of the schemes powering them. I do five things to make a project archived. There's no really archiving injera, but I call it archived it's really read only first I changed the project. Long name I pre penned X and the word archived in front of the old name. The X helps the projects be listed the bottom of the list in the admin pages. Next, I changed the category. I put all of the archive projects in a category called X Archived. After that, I change the icon for the project. I use a big, scary red lock icon that stands out. After that, I put a big red message on the summary page, explaining to users that the project has been archived. The data is available in a read only mode, but no new issues could be created or updated or transition. And then finally, I changed the permission scheme to one where the browse permission is given to dear users. But no other permissions are granted, and I get rid of the notifications game. There's no sense of having a notification scheme to a project where there's no activity. So I try to do this exercise quarterly, and last time I did it, I found that 30% of the projects were unused, so I made all of those read only that I removed those unused schemes and was able to reduce my total scheme count by 20%. And then I further reduced the database record count by 30%. Now, when you want 30% less junk in your database, I bet your database administrator would 19. Multiple Instances: at one company, the Finance Department noticed that they were paying for two separate Jiro licenses. One team was using a cloud instance, and another team had a server instance running on an old machine under someone's desk. So the teams had to decide which application would be retained and how to merge the data. Now, one day, you may need to merge multiple gear instances, move data to a new instance or even start over from scratch. So here's my instance. Comparison checklist. First, compare the strengths and weaknesses of each set up and also determine how different your application is from jurors. Default. Now you may be attempted to retain the best instance with the best hardware or the best database, but it's only the best if it's stable, well maintained and likely to remain an inventory for the long term. Next carefully consider the big differences between applications, so consider the features and connections that must be retained and others that can go away . Don't retain or migrate old data or configurations that you don't really need. Next. Consider who is best equipped to make and execute merge and migration decisions. You want to keep emotion or loyalty out of the decision process. The end goal should be to create the best overall environment and experience for your users . And finally consider how merging data from another system might clutter the cleaner system . So think about cleanup actions that you can perform on both applications before emerge. Think about any changes you can make to prepare for an easier migration and make sure both instances are on the exact same version. 20. User Management: At one company, there were 1000 active users, but only 700 employees. How does that happen? Well, users were not made inactive when they left the company. There was no pre or post departure user cleanup. Instead, I recommend the following first, create your own user management strategy so user management is more than just adding new users as they joined the company. Your user list needs regular attention to remain accurate. Consider these questions. How will you support new and departing users? How will you handle and receive access requests and remove ALS, And how will you handle permissions related requests? Next, determine access and credential standards. Here are some questions How do users access the application? What credentials do they use? How does the new user securely received their credentials and is access local to the application? Or is it managed by another system? Answer these questions and make sure all of this information is somewhere where users can access it. And here's a tip. When your application grows to over 50 users, it's time to consider a central user directory. There are many options you can manage users through active directory Google APS crowd, which isn't it last seen application or other services? And finally, make sure you have a procedure for deactivating user accounts. The easiest way to manage a departing users account is to have them assist with their cleanup activities before they even leave. Also, make sure your company notifies you when employees is about to leave if the employees can't help with their own cleanup, such as deleting unneeded filters, boards, dashboards, removing favorites as their manager for assistance. 21. Standards: this screenshot shows a special icon on any Jiro create screen and the link shows and users . The issue types statuses on other values already available in your instance. So this is a really easy way to communicate what options are available when a user asks for a new project. Alright, so back to standards you need to set them before you start building new custom options, your admin team should decide how many of each will be offered and for what purpose. And if you set standards now, it will help you keep your application Uncluttered and easy to maintain. Trying to make all your configurations as simple and as generic as you can so they could be easily shared between multiple projects and multiple teams and don't make custom is ations that Onley apply to a narrow use case. So for any customization request, determine the impact the application now and in the future and always find that if a user asked for a very specific implementation, I need to ask Maura about what they're really trying to dio, because there could be a better way. So let me give you two examples. One. We get a lot of requests to create a group. So we create the group. We add the users we tell the request of their group is ready and they tell me the group is broken. I say, What do you mean? It's broken? Well, they were trying to add the group as a watcher. Well, that's not a deer a feature. So if I had just asked for more information about what they were trying to accomplish, I could have saved myself The throwaway work of making a group they didn't really need. Another example is when a user asked for a new issue type. Now you and I know that the reason to create a new issue type in a project is for when you want a different set of work flows or a different set of screens or both within the same project. But a lot of times, that's not what the user actually wants. They just want to distinguish er away to group work in one of two buckets, so there are better ways to do that. You could use a component. You could use a custom field. You could use a label many options, but you don't wanna have lots and lots of issue types. So instead don't make custom is ations just to make one user happy. Sometimes you have to be the bad guy as the deer admin and deny a request. I always cite the integrity of the application when explained to my users while they're customization isn't a good idea.