1. Paul Coffey Employee Central Engineering Manager
PS Jira Training
Paul Coffey
Employee Central Engineering Manager

2. Introduction When to create a Jira
In depth review of the fields that make up Jira
Learn how to minimize time-consuming back-and-forth with Engineering by providing all pertinent information at time of creation.
Resolution Workflow – how to find out what actions Engineering have taken on your ticket.

3. PS Jira Defects resolved in past year

4. When to create a defect in Jira
Confirm that the issue is not caused by bad configuration – check the Implementation Handbook
Make sure the issue has not already been logged in Jira (more on this later)
For Learning tickets, you must replicate on one of the PS Test environments in Sales Demo prior to Jira creation (ACEIN0167, ACEIN0168).

5. Top Nav Bar
Find Issues
Create Issue
Build Schedule
Patch Schedule

6. Searching for duplicates
Rather than spend the time creating your own Jira, you might find one already open.
You might be able to reference similar, but closed issues, to help the Engineer understand your issue.
You might find a workaround or a solution to your issue, and avoid the whole Jira process altogether!

7. Searching for duplicates (option 1)
Quick Search
Using quick search, you can enter key search terms and find jiras
You can enter a Jira number here as well and the corresponding Jira will appear
Quick Search

8. Searching for duplicates (option 2)
Filter search
Clicking on the Issues link will bring up the Filter Search.
This allows a much more detailed search.
Search by Project, Status, etc. This is helpful when you are looking for a particular Jira, and the Quick Search returns too many results.
Issues Link

9. Creating a Jira 1. Create Issue 2. Choose the Project (module)
3. Choose the Issue Type

10. Issue Type Definitions
Defect - A problem which impairs or prevents the functions of the product
Enhancement - An improvement or enhancement to an existing feature or task
New Feature - A new feature of the product, which has yet to be developed
Task - A task that needs to be done.
Performance - A problem related to the application's performance
Security - A problem related to the application's security

11. Jira Creation Step-by-Step

12. You should chose the version in which the defect was found.
Creating a defect
Affects Version:
You should chose the version in which the defect was found.
Why this is important:
1. Affects version drives Engineering dashboards, specifically after a release.
2. Helps the QA team determine what environment they need to test on to verify a defect.

13. Example of GOOD summary
Creating a defect
Summary
Please be as specific as possible.
Do not include customer names in the title, as this may affect more than one customer!
Why this is important:
A good summary helps everyone quickly find and understand your issue!
Example of BAD summary
“Forms not creating”
Example of GOOD summary
“Forms not creating when head of hierarchy has special characters in the userID”

14. Please be as specific as possible.
Creating a defect
Description
Please be as specific as possible.
Any information apart from Replication Steps (separate field – will reference later). Please keep to the point and unemotional.
Why this is important:
A good description helps everyone quickly find and understand your issue!

15. Creating a defect Why this is important: Attachment:
The following information should be included in EVERY Jira:
Screenshots or video showing replication of issue to support replication steps
ALL relevant xml files/templates
Other relevant files such as picklist files
Why this is important:
Engineering needs to be able to reproduce a defect before they can ascertain root cause or begin working on a fix.

16. If the customer is in implementation please use “Go Live Issue”
Creating a defect
Issue Category
If the customer is in implementation please use “Go Live Issue”
Why this is important:
This is used by Engineering to determine who logged the defect – CS, PS, Sales or QA. If you do not set this field correctly, there may be a delay in Engineering beginning work on your issue.

17. This helps Engineering track who is affected by this defect.
Creating a defect
Customer Name
List your customer name here – not in the Summary!
If you did not create the Jira, but know that your customer is experiencing the issue, please add your customer name here.
Why this is important:
This helps Engineering track who is affected by this defect.
Searches are done in this field and in the description – so it doesn’t hurt to use it in both places!
Also, consistency is key! Try to stick to one spelling type (for example WalMart, wal-mart, etc.)

18. You can choose more than one component by using ctrl+click.
Creating a defect
Components
Components further define the area of the module that is affected. Please try to find the component(s) that best match your issue.
You can choose more than one component by using ctrl+click.
Why this is important:
Engineers often have specific skills and work on specific issues. Identifying the component correctly will help the team assign the issue to the right person, and avoid delays.

19. The SLA drives response time.
Creating a defect
SLA
For a full definition of each and description of response time – go here
P1 (Urgent): The software on the production system is down (crashes) or is not operational.
P2 (Important): The software on the production system is operational but has a major functional loss that impedes transactions.
P3 (Necessary): The software on the production system has a functional loss that does not impede transactions from being completed, but affects performance or user quality; or a suitable work around can be employed; or the functionality is not immediately necessary.
P4 (Minor): The software has a cosmetic or grammatical error that does not affect performance or stability of the system, or Customer has questions regarding use of the product.
P5 (Enhancement): Request for a new feature or new functionality that does not already exist in the product.
Why this is important:
The SLA drives response time.

20. Creating a defect Priority Escalation: Issue is escalated.
Critical: Crashes, loss of data, memory leak.
Major: Major loss of function.
Normal: Normal issue.
Minor: Minor loss of function, or other problem where easy workaround is present.
Trivial: Cosmetic problem like misspelled words or misaligned text.
Contract: Issues that have been contractually committed to. (This should only be chosen by the Engineering / Product Management team.)
Why this is important:
Priority helps the Engineering team prioritize their defects. ‘Escalation’ is widely used in Engineering dashboards.

21. Escalation Business Reason
Creating a defect
Escalation Business Reason
If you need to escalate an issue, please fill out this field. This provides valuable context, and helps engineering management prioritize the issue correctly.

22. Creating a defect Why this is important:
Helps with prioritization. If an issue has the same SLA & Priority, then all other things being equal Engineering will prioritize issues with closer PS Due Date
PS Due Date
This date is set by Professional Services to indicate when the customer needs the issue to be resolved. If there is no hard date that an issue needs to be resolved, please leave this blank.

23. Creating a defect Why this is important:
Replication Steps
This information is vital and should ALWAYS be completed. These should be clear and descriptive. They should be numbered.
Example:
Log into ACE123 instance.
Proxy as userID aaa
Click on the Recruiting tab
For requisition 1234, click on the candidate column
Etc….
Why this is important:
Everything stems from the replication steps. Remember, someone who has never seen the issue or configuration needs to understand and accurately reproduce this!
Note
If you include a separate document with the replication steps and screenshots, that’s ok – but please note the doc name in this field!

24. Browser Type and Version
Creating a defect
Why this is important:
Again – reproduction is extremely important. This will help the Engineer reproduce in the correct environment. An issue may be occurring in IE8, but not IE9, for example.
Browser Type and Version
Include the browser type and version that this was found on.
This is specifically important for browser specific issues.

25. Creating a defect Environment: Why this is important:
Include the release, server and timestamp information which is found by choosing “Show version information”
Why this is important:
This helps Engineering test this in the right environment. Can be used to get server logs.

26. Creating a CO ticket for logs1. 2.

27. Creating a CO ticket for logs3.

28. Creating a CO ticket for logs4.
Why this is important:
It can take up to a day to get production server logs. If you create the CO ticket when you open the defect, logs will be available to Engineering when an engineer first looks at the ticket.

29. Investigation Stage Why this is important:
Engineering create dashboards to identify Jiras that require a response from Engineering.
Investigation Stage
Tells who the Jira is with. If Engineering requires more information from PS, they will change this to “Awaiting CS/PS Response”

30. Resolution Workflow

31. Status Definitions
Open - The issue is 'New' and ready for the assignee to start work on it.
Bug Confirmed – QA/Dev has verified that this is a bug.
In Progress - 'ASSIGNED'. This issue is being worked on by the assignee.
Resolved - This issue has been resolved (Resolution = Fixed, Duplicate, Invalid etc)
Reopened - This issue was once resolved, but the resolution was deemed incorrect. From here issues are either marked assigned or resolved.
Closed (Verified) - The issue resolution is correct. Issues which are closed can be reopened.

32. Resolution Statuses

33. Fix Version How it works:
The Fix Version does not represent a commitment. This Fix Version is more like a PLANNED Fix Version. Most times this date is met, but sometimes it changes due to the shifting priorities of other builds.
Often times, you will not see communication in your Jira until Code Complete of the release prior to the one set in your Fix Version.

34. Patches
How it works:
A patch ticket is created when an issue needs to be fixed in the current production release – when the customer cannot wait for the next major release.
Patches go through a three-step approval workflow.
The Fix Version of the underlying linked Jira will still list the next major production release.
Click on the patch’s Fix Version to get the date the patch will be deployed to customers.
The patch is confirmed for release when the patch Status is “Verified”.
The patch schedule is listed at the top of every Jira page.