Creating a JIRA Ticket
This procedure details the minimum requirements for creating a JIRA ticket to ensure the tickets are consistently filled out and contain sufficient information/ references to information for the assignee to do the ticket. Before creating the ticket identify which project the ticket is for. Ensure the ticket does not include multiple projects on JIRA if it does a ticket should be raised for each project and if there is commonality of task the tickets in other projects should be referenced (see Linked Issue). This should ensure each project has proper audit trails of work done.
JIRA Tickets should reflect work that is actually required to be done it should not be a wish list or a possible list. Wishes or possible developments should be put on the appropriate confluence project page and after discussion and definition will be turned in to a ticket for the project.
Fields that must be Populated
Field | Content | Notes |
|---|---|---|
Issue Type | Task/Bug/Improvement/New Feature | Options vary depending on the project definition. Choose most appropriate |
Summary | Text | Brief heading clearly indicating what ticket is about |
Description | Text | Detailed description explaining what is required/issue etc. Should include links to further documentation or additional test files as required. Context how dis the issue seen/what is the request trying to solve and approriate details Expected result/required solution depending on the nature of the ticket Any other supporting or helpful information such the page a field needs adding to etc. |
Component/s | Drop Down | Select any of the listed components that this ticket applies to. Not all projects will have components defined. |
PID Data | Text | If any PID information is required for the Assignee to do the Ticket it should be put in this field. This prevents the PID info being included in emails and summaries. |
Priority | DropDown | Select an Appropriate priority |
Fields that could be Populated
Field | Content | Note |
|---|---|---|
Affects Version/s | Version No (can be more than one) | On Software related projects where each release has a version number this should indicate which version was being run when the issues was found. This is primarily applicable to Bugs |
Due date | Date | When required by a deadline this date should be set. Leave blank if unknown and it can be used to schedule the ticket. |
Linked Issues | relates to/blocks/is blocked by/causes/is caused by/duplicates/clones | If a ticket has related tickets or has an effect on other tickets this filed should be used to indicate which ticket. (Similarly the other ticket should be updated to reference back to this ticket) |
Issues | Ticket References | Links to previous field and lists tickets that relate |
Assignee | User Name | If you know who should be handling this issue then add them to the assignee field |
Epic Link | Name of Epic this ticket is associated with | If Epics are being used to group a body of work broken in to separate tickets then this field should show which epic the current ticket is part of. |
Labels | Label for task | Some times it is useful to label tasks with more resolution than the use of components can provide or because components are not appropriate for he given project. |