Jira Scary Stories | Rachel Wright | Skillshare

Playback Speed


  • 0.5x
  • 1x (Normal)
  • 1.25x
  • 1.5x
  • 2x

Watch this class and thousands more

Get unlimited access to every class
Taught by industry leaders & working professionals
Topics include illustration, design, photography, and more

Watch this class and thousands more

Get unlimited access to every class
Taught by industry leaders & working professionals
Topics include illustration, design, photography, and more

Lessons in This Class

16 Lessons (19m)
    • 1. Introduction

      1:11
    • 2. Interactive Poll

      0:45
    • 3. Security Horror

      0:57
    • 4. Security Horror - Results

      1:25
    • 5. Next-gen Project Poltergeist

      6:50
    • 6. Next-gen Project Poltergeist - Results

      0:04
    • 7. Password Fright

      0:44
    • 8. Password Fright - Results

      0:49
    • 9. Add-on Upgrade Scare

      0:48
    • 10. Add-on Upgrade Scare - Results

      0:23
    • 11. Reporting Nightmare

      1:50
    • 12. Reporting Nightmare - Results

      0:36
    • 13. Backlog Burial

      0:47
    • 14. Backlog Burial - Results

      0:03
    • 15. Bonus: R.I.P. Old Issue Tracker

      1:35
    • 16. Resources

      0:42
  • --
  • Beginner level
  • Intermediate level
  • Advanced level
  • All levels
  • Beg/Int level
  • Int/Adv level

Community Generated

The level is determined by a majority opinion of students who have reviewed this class. The teacher's recommendation is shown until at least 5 student responses are collected.

15

Students

--

Projects

About This Class

Welcome to tales of spooky security, freakish custom fields, and the potential horrors of user-created projects and issue types.

I’ve been using Jira since 2011 and have seen some scary things over the years.  This course will show you some problems to avoid and give you ways to respond if they occur.

You’ll hear about:

  • security and password horrors,
  • the Next-gen project type in Jira Cloud,
  • upgrade related add-on problems,
  • and bad data management practices.

As new scary experiences occur, I’ll add their stories to the course.  Go to the next lesson to join me as we descend into Jira madness!

Meet Your Teacher

Teacher Profile Image

Rachel Wright

Author, Jira Strategy Admin Workbook

Teacher

Rachel Wright is an entrepreneur, process engineer, and Atlassian Certified Jira Administrator.

She started using Jira and Confluence in 2011, became an administrator in 2013, and was certified in 2016.

Rachel also uses Atlassian tools in her personal life for accomplishing goals and tracking tasks.  Her first book, the “Jira Strategy Admin Workbook“, was written in Confluence and progress was tracked in Jira!

Help for Jira and Confluence Users and Administrators is here!  Visit jirastrategy.com for templates, worksheets, and materials to help you set up, clean up, and maintain your applications.

See full profile

Class Ratings

Expectations Met?
  • Exceeded!
    0%
  • Yes
    0%
  • Somewhat
    0%
  • Not really
    0%
Reviews Archive

In October 2018, we updated our review system to improve the way we collect feedback. Below are the reviews written before that update.

Why Join Skillshare?

Take award-winning Skillshare Original Classes

Each class has short lessons, hands-on projects

Your membership supports Skillshare teachers

Learn From Anywhere

Take classes on the go with the Skillshare app. Stream or download to watch on the plane, the subway, or wherever you learn best.

Transcripts

1. Introduction: Hi, I'm Rachel, right? Certified Ghira, administrator and author of The Gear. A Strategy Admin Workbook. Welcome to the jury. Scary Stories presentation. You'll hear tales of spooky security, freakish custom fields and the potential horrors of user created projects and issue types. I've been using dearest since 2011 and I've seen a lot of scary things. This presentation will show you some problems to avoid and give you ways to respond. If they occur, you'll hear about security and password horrors. The next Gen Project Type into your cloud upgrade related out on problems and bad data management practices. And as new scary experiences occur, I'll have those stories to the course. Go to the next lesson and join me as we descend into your madness. 2. Interactive Poll: gear is great, but if you're not careful, core configuration decisions will haunt your days. The ghosts of former custom fields will rise from the dead during maintenance. Remnants of past add ons will haunt your file system, never freeing you from their ghastly grip and bad security practices will unleash their evil on your application for years to come. But all of this terror and horror can be avoided after each story is alive. Poll. You'll select what you would do to fix the problem launched this Ural now on your phone or laptop. 3. Security Horror: Let's talk about some horrendous security decisions. Here's a real scenario. A small company has dear a server and uses it last aeons crowd product to store user credentials. The tools are publicly accessible on the Internet, and there's no SSL that's already a little scary, right? Well, one day the CEO reports that a few users have for gotten their dear passwords and that he understandably doesn't have time to deal with password issues. There are many things that could be done. How would you improve this situation? Visit the euro and take the pole? These are opinion questions. There's no one correct answer. Answer the first question and click the vote button, and we'll review the results and talk about what happened. 4. Security Horror - Results: which poll options did you select? I selected all of them except record passwords, so you can remind users later when they forget. I don't want to know a users password, and I certainly don't want to write it down and remind a user. So here's what really happened. The CEO decided that each user would have the same application password, for example, if the company was named Acme Software. The password for everyone was Acme Ajira. That's just one step better than the password being the word password. Now this was a security and compliance nightmare. Users could all log in as each other, and the audit trail was now useless. And since there was no firewall, former employees could log in just by knowing the name of any current employees. I wonder how many users logged in as the CEO. Another thing to consider. I've been involved in two legal investigations where I had to prove something did or did not happen injera by a certain user. If all of your users air ableto log in as all of your other users, there's no ability to know who did what avoid this situation at all costs 5. Next-gen Project Poltergeist: at last he and announced a new feature for Jiro Cloud. There's a new type of your project that doesn't share its configuration with other projects . They're called next gen projects, and it's also the new name for the agility projects. They're also sometimes referred to as independent projects. Independent projects don't share or affect any existing dear objects or schemes like custom fields, issue types, work flows, screens or permissions. So far, so good. But here's the scary part. Any regular dear user can create a project. It's issue types, and it's custom fields any user. There's no need to engage the application. Admin team and users can create new projects whenever they want. I initially cringed at the thought of cleaning up the new messes that end users will inevitably create. I've spent many years fixing poor decisions made by application. Add men's and now you're telling the end. Users with even less knowledge and application management experience are unleashed on the config. Yikes! Atlassian also announced the 2000 cloud user limit was lifted to 5000 users, and now even more people can create a bigger mess. I've since calmed down a bit, and I'm trying to be open to this change. I'm looking for ways to embrace it and also manage the potential scariness. Let's take a closer look at this new project type. First. It's important to know that the ability to create independent projects is configurable. It's a global permission, so you can decide which groups, if any, received this power. You don't have to use the default anyone setting. In my book, I recommend creating an ambassador's group. It's a small team that represents your user base. They help when you need to execute changes to your current application or communicate the change request process. Use your ambassadors to disseminate information, answer common questions and service liaison between the application admin team and end users. Existing project leads are likely good ambassador candidates. Maybe the same group can be trained and be responsible for creating next gen projects, too. I did a quick test to see how these new projects work. I tried to create a new issue type called Epic, even though as a juror, it men, I know that this type already exists. Juris, stop me from creating a second issue type with the same name, which is good, but dear can't prevent other human cause problems. Like similarly named types, florals and misspellings, I was able to create a new issue type called Epics with an s. Now, this project has both epic and ethics, which is simply a standard issue type like any other. Now, this is not pretty. But luckily, this unfortunate action is constrained to this one independent project. This new epics issue type is not on the global issue types Admin page. The only global downside I can think of is all users will see both options and the Jake UL search. Which type should you pick? I don't know. And your end users won't know either. Next, I created a custom field with the new Fields designer feature. I created a field called Date and selected. The type is text instead of date like it should be. It's a common mistake, and end users are bound to make it in the screen shot. You can see my lovely new field on the right, and it's purposely ridiculous value. This team won't be able to properly sort or query data in this field. And of course, this field will show up in Jake. You Well and finally, what might happen if lots of users create lots of new projects? You might have 300 projects one day and 400 the next. Users might duplicate projects that are already there. Look at the screen shot. Which of the three marketing projects should a new issue be created in and users might not know? You'll likely get to use the move, command more often and see more records in your moved issue. Key database table and users might create projects that just might not belong injera. So personal spaces are great in confluence, but can imagine if every employee also wanted their own gear a project or two. Scary. Also, there are no bulk tools to manage these projects when they're no longer needed. I've recorded just a few of the pros and cons I have discovered so far on the pro side. Users have more power, letting add mons focus on other work. This is helpful if there's a bottleneck in project creation or if your admin team just isn't as responsive as they should be on the con side. What are the long term impacts? Will all these new projects issue types and custom Fields Impact performance. How that database size? How will the new independent projects play alongside the traditional projects? It's all unknown right now for reporting. How will that work across multiple projects if they're configured differently? How will reporting the impacted when you now have a new custom field called status or four custom fields called a sign E or a due date field created as a text field? Finally, if you want to migrate from to your cloud to do your server or data center the next Jim Projects need to be changed to regular projects first, and I'm not sure how to do that quite yet. We'll likely uncover many more pros and cons as we further explore these features. So what do you think? Are you open to this change? Answer the next poll question. 6. Next-gen Project Poltergeist - Results: Here's how I voted. 7. Password Fright: I have another scary password story to share. At one company, the security team noticed that users were including their passwords in support requests. In the example, screenshot John has shared his password for the expense reimbursement application. Now other users could log in as him and see his bank account details. Also, since the application is linked to Active directory, other users now have this password for other network Resource is, too Not too smart. Dawn. How would you handle this scenario? Have a look at the options in the poll question and click the vote button. 8. Password Fright - Results: I chose reset, exposed passports and remind users not to share passwords. So here's what really happened. The security team responded by devising a long Jake you a query to find the majority of the instances. And apparently this had been going on for some time because they found over 2000 problem issues and begin manually removing the passwords from the description and comment fields. Well, I wish I was making this up. Unfortunately, the security team didn't realize that the password remains exposed in an issues history and further email notifications were sent for each issue update. This likely drew more attention to the exposed password. 9. Add-on Upgrade Scare: Here's a silly mistake I made. I was testing Ajira upgrade and discovered two things. One, one of my heavily use plug ins wasn't compatible with the upgrade version and to the plug in had changed from free to paid. I click the buy now button on the manage add ons Page, assuming it would take me to a shopping cart with pricing information. But I assumed wrong. Instead, it immediately installed on unlicensed version of the new plug and goat. All of our work flows broke, and I was inundated by reports of license errors from users. What would you dio answer the next poll question? 10. Add-on Upgrade Scare - Results: Here's how I voted. So here's what happened. I had to quickly generate a free trial code to restore functionality. Then I sheepishly contacted the purchasing department to secure emergency funding for the new plug in, and unfortunately I did this all in production. 11. Reporting Nightmare: Let's talk about reporting. Consider this really scenario. The support team uses the Components field to categorize which application a request is floor the team's support? 70 applications. But for some reason, Onley nine are in the component selection list. There's some obvious selections missing, but there's at least one name other to tide them over until the others are needed. It's a good practice toe always include an other option for any selection field. But then the support team lead sends an email to the team with the information displayed. The email contains instructions for labelling any applications, not in the components list. They want to also use labels because they were worried the components list would get too long. Over time, it's almost inevitable that users will deviate from the agreed upon label. Let's take the label QuickBooks. As an example, users might start out entering Q B as requested, but eventually, other label formats are likely to appear soon. You have a mess of labels and no way to effectively curry for them. Also, you have to know which application has its own component and which is part of the other component. It's a real mess. Finally, the label strategy was sent via email. So everyone has already lost that message, and new users will never even have the label information. So how would you handle this situation? Answer the next poll question. 12. Reporting Nightmare - Results: Here's how I voted. So here's what happened. I explained the pros and cons of components versus labels, and I also recommended that they add any missing selections to the component lists. Now it's really early, and the team has decided to stick with their original idea of components and labels for a little while. But I predict that in about a year's time they'll see that the reporting is suffering and they'll probably clean up their components lists. My fingers are crossed. 13. Backlog Burial: at one company. The backlog was where ideas went to die. Any time anyone had an idea, they created a juror issue for it. Issues were created without regard for importance scheduling, strategic priority or business benefit. And that led to a huge, bloated and unusable backlog. The list was so big that project managers couldn't separate the good ideas from the bad product. Owners couldn't get their high priority. I didn't scheduled team leads, couldn't plan their work, and the list of back luck items took forever to load. How would you improve the situation? Take the pole now. 14. Backlog Burial - Results: Here's how I voted. 15. Bonus: R.I.P. Old Issue Tracker: I started using Jura many Halloweens ago. We transition from an old issue tracker called Test Director and in honor of the Halloween holiday and to ease the change management process, I conducted a funeral for old software. I decorated the office with spider webs and gravestones hung up screenshots of the worst error messages, and a team member wrote this eulogy that I'll share with you. We are gathered here to mourn our previous issue. Tracker, Test Director. The ancient and unsupportive bug tracking system has died born to Mercury Interactive Corporation in an error. When Activex seemed like a good idea, test director was best known for his finicky and bug ridden interface, an unreasonably small character limit in the comments field. His inability to run in any browser better than Internet Explorer seven combined with his skill in completely overriding issues with data from other issues, made him truly unique in his field. Test director will live on in the memories of users who relished the irony of tracking bugs in a bug ridden tracking system. He is survived by it last See injera. This tribute was created by Scott Bradford. Scott is a Web technologist, developer, writer and manager 16. Resources: did you hear about the deer instance? With 127 admits, How about the instance? Sending issue update notifications to former employees. Take my top gear Admin mistakes course for 20 mistakes like these to avoid. I also created a course to help you clean up too many custom fields at another to design smart work flows for your business teams. Also, my Jura Strategy Admin Workbook contains 150 recommendations and 50 worksheets for setting up cleaning up and maintaining Jura. With these resource is, you can keep your instance out of the scary gear a swamp.