Jira Cheat Sheet

JIRA Cheat Sheet This is a brief introduction to using JIRA for project management in the IT and software development environments. Get started with JQL and advanced search in Jira. This guide will teach you JQL syntax and how to visualize results on your Jira dashboard. Download the Excel plug-in or Google Sheets add-on to export queries in your favorite spreadsheet tool. Download JQL Cheat Sheet. Read the JQL tutorial blog. Text 'Atlassian jira'10' Add ^ with a boost factor (a number) to the end of a search term e.g. Atlassian^4 jira Fields A simple query in JQL (also known as a “clause”) consists of a ˜eld, followed by an operator, followed by one or more values or functions. JQL Cheat Sheet. This document was created to be linked as a cheat sheet and reference guide to users in the Jira system. It is our hope that this will make things easier to understand and harder for issues that people have to fall through the cracks. Microsoft Word - JIRA Cheat Sheet.docx Author: ralmeida2 Created Date: 5/29/2016 9:12:45 PM.

Jira Cheat Sheet

Skip to end of metadataGo to start of metadata

Atlassian User guide for JIRA: https://confluence.atlassian.com/display/JIRA/JIRA+Documentation

Jira Query Cheat Sheet

Download intel sound cards & media devices driver. This flowchart is to be used as an overview of the Jira project that I created for end user support issues. It will outline the statuses that we are currently using and the ways that they are to be used. If there are any questions or feedback on this please send an e-mail to predict-hd-help@uiowa.edu for support. You may also download a copy of this Wiki for your own records here.

For the actual flowchart I have a Visio document that outlines the process located in Sharepoint. You can download the PDF that we have created for a more visual representation of how the flow of the tickets/issues should go.

Ticket Workflow:
1. Ticket is created by end user, SA, or IT staff.
2. Ticket gets assigned to the correct IT person and affected users and SA’s are put onto the ticket as Watchers along with relevant IT personnel.
3. Before reviewing the ticket, IT staff clicks on Start Progress status
  1. This will then send out an automated e-mail to all watchers on the ticket so that they see that IT has begun looking into the reported issue.
4. IT member assigned to the ticket then reviews the issue. Criteria as follows:
  1. Is there enough information from the user on the issue for us to look into the matter?
  2. Does this require a remote support session through GoTo Meeting
  3. Is this something that is an immediate need, or does the issue need to be put on hold?
5. If there is not enough information from the user on the issue, IT will then send out an email to the user and SA requesting as much information on the issue as possible. Before sending the email IT will copy the entire email and click on the status of Waiting on End User in Jira. Then IT will paste the above created e-mail into the comment field and post it while sending out the email.
  1. The users and SA’s should then receive 2 emails about this. One from Jira and the other from the IT member that will contain information about the status of the issue.
6. Once a response is received, the IT member will then click on the Start Progress status in the ticket.
  1. Again the user and the SA will receive notification that the ticket is being worked on again.
7. IT will review the information that they now have using the above listed criteria again.
8. IT member will then make updates on the ticket as work is being done through comments on the ticket and if work is stopped for whatever reason then they will click on the Stop Progress link in the ticket to notify the users and SA’s that work was stopped
  1. This simply means that if we get pulled off to work on another issue that is a higher priority that we should be commenting that in the ticket and then stopping progress. Once the ticket is back to being looked into Start Progress should be clicked again and notification sent out that it is being addressed again.
9. This simply means that if we get pulled off to work on another issue that is a higher priority that we should be commenting that in the ticket and then stopping progress. Once the ticket is back to being looked into Start Progress should be clicked again and notification sent out that it is being addressed again.
10. Once we believe that we have resolved the issue, we should be sending out the fix to the user and the SA’s for testing. At this point the ticket should get changed to Waiting on End User again along with another email from the IT member.
11. After testing is complete and the IT member has been notified that the issue is resolved, we will click on the Resolve Issue status and provide an update along with the resolution
  1. Once this has been done another automated notification will go out to the end user and the SA’s to let them know that the issue is in a resolved status.
12. Depending on the issue we may close the issue immediately as well by clicking on the Close Issue status in Jira.
  1. This will again notify all watchers on the ticket that the issue is considered closed.
  2. If the issue is something that we think is resovled, but time needs to pass then we leave as resolved and can reopen the issue if it occurs within that time.
  3. If we resolve an issue and the issue is not resolved to satisfaction, an SA can go into Jira and click on the Reopen link in the ticket to notify IT and the users that the issue still needs to be addressed.
Status Workflow:
1. The Statuses of Jira are the important keys to communication. If the workflows are not followed as intended then the system will not notify anyone. Once all the relevant people have been added to a ticket as Watchers on the ticket the status flow as interpreted by IT should be as follows:
  1. Created – This status is the intial staus that a ticket is given when it is first created. It is also retained when a ticket is reassigned to the correct person that will look into the issue. It will notify the reporter (creator) of the issue and the Assignee.
  2. Start Progress – This status should be selected once a ticket begins to be reviewed. It will take the ticket out of Created status and will not be able to get back to the created status. It should be used anytime that someone is working on an issue. It notifies the assignee and the watchers that the ticket is being worked on.
  3. Stop Progress - This workflow is used by IT to notify the user that we are no longer working direclty on the issue. IT has defined the interpretation of this to be such that to properly communicate with a user about an issue and to avoid false positives or open ended progress, we will let you know once the work has been stopped on an issue. Generally this is prefaced by a Comment notification or you should receive one after the work has stopped. If not then there is something that was an emergency that caused this.
  4. Waiting on End User – This status should be used for a ticket that needs more information for support or end user testing, It is meant to specify to all that are on the ticket that IT is waiting for some piece of information and that they cannot work through the issue or resolve until that information is given from the users or SA’s. It will notify all that are Watchers on the ticket.
  5. On hold – This status is to notify everyone on the ticket that IT has placed the ticket on hold. The reason should be commented into the ticket so that all know why the delay is needed and it should notify all the Watchers on the ticket. Examples could be things like an emergency that took higher priority, awaiting hardware for repair, or awaiting delivery of another machine to a site to test.
  6. Resovle Issue – This status indicates that we have resolved the issue to the best of our ability and that the end users have tested complete to their satisfaction. It will notify all Watchers on the ticket.
  7. Re-open Issue – This status should only be used for when IT believes through testing that the issue was resolved, but then shortly after the issue reappeared. It will notify all the Watchers on the ticket and the Assignee
  8. Close Issue – This status is to be used when an issue is resolved and all things tested to satisfaction. It could also be used in a situation where the issue could not be duplicated, or there is no loner an issue. All watchers and assigned members are notified.
Key Tips for your consideration:
1. If the status is, “started” or “closed”, you probably don’t need to read it, unless the topic is something that you’re directly involved in.
2. If the status is, “resolved” and you were involved in it, you should definitely read it to make sure it’s resolved to your satisfaction.
3. If it says “comments”, you might want to glance at the top entry, which will be the most recent. The history of that particular issue, will always be further down in the body and in a different color, so you can read it if you want.

This document was created to be linked as a cheat sheet and reference guide to users in the Jira system. It is our hope that this will make things easier to understand and harder for issues that people have to fall through the cracks. It is also our hope that it will improve both the level of support that we provide and communication that we offer. If there are any questions or feedback that anyone has please email predict-hd-help@uiowa.edu so that we can continue to improve our system and support. Thanks.