Attention: Confluence is not suitable for the storage of highly confidential data. Please ensure that any data classified as Highly Protected is stored using a more secure platform.
If you have any questions, please refer to the University's data classification guide or contact ict.askcyber@sydney.edu.au
Jira Card Best Practice
- Liz Enright
- Mai Ha
Summary |
|---|
This page covers the best practice for Jira tickets on the TAPSS board. |
Table of Contents |
|---|
Card Definitions
Issue Type | When to use | Template | Useful Example |
|---|---|---|---|
Story | This is new functionality that needs to be created. Examples:
| Persona + Need + Purpose As a I want to So that Acceptance Criteria: GIVEN WHEN THEN AND |
|
Bug | Existing functionality is not working as expected. Examples:
| Feedback/Bug Description: What is not working: Steps to reproduce: Expected behaviour (what should the system be doing)? Business Impact? (e.g. number of users or records affected) Data used: Screenshot/Error logs: Link to the record: Teams impacted? |
|
Epic | This is an large overarching body of work that will be broken down into different tickets. Examples:
| Summary: In Scope: Out of scope: Any known dependencies: Teams impacted: Project team: |
|
Improvement | This is to update or change existing functionality. Examples:
| Persona + Need + Purpose As a I want to So that Acceptance Criteria: GIVEN WHEN THEN AND |
|
Task | This is for non-development related activity. Examples:
| Issue: Why are we doing this? Impact? (e.g. number of users or records affected) Teams impacted? |
|
Xray Test | For use of the Testing team. | N/A | N/A |
Test Set | For use of the Testing team. | N/A | N/A |
Test Plan | For use of the Testing team. | N/A | N/A |
Test Execution | For use of the Testing team. | N/A | N/A |
Risk | Not in use. Do not use. | N/A | N/A |
Issue | Not in use. Do not use. | N/A | N/A |
Precondition | Not in use. Do not use. | N/A | N/A |
T-Shirt Ticket Sizes
Ticket sizes are different based on whether it’s an Epic or any other ticket type. Epics will have longer time frames due to their larger scope.
Standard Ticket Sizes
T-Shirt Sizes | How long will it take? |
|---|---|
XS | 2 hours |
S | 1 day |
M | 3 days |
L | 5 days |
XL | 10 days |
Epic Ticket Sizes
T-Shirt Sizes | How long will it take? |
|---|---|
XS | Within 1 sprint |
S | 1 - 2 sprints |
M | 3 - 4 sprints |
L | 5 - 6 sprints |
Jira Fields
BA working on tag - this card is being reviewed and finalised by the BA in conjunction with the stakeholders, to get to DoR for backlog refinement
Flagged - where the card is not blocked but there something needs to be resolved within the sprint. Once flagged, enter a free text explanation of the issue for resolution.
Card Priorities
Priorities for Jarvis tickets change depending on the ticket type. Jarvis as a University application has been classified as a P3 application.
Bugs
Here are some considerations that will determine the priority of a bug.
How many people does it effect?
Is it reputational risk? Does it effect our donors?
Is there a dollar amount that’s impacted or high volume of Contacts involved?
How often does the issue impact processes? Does the process occur daily, weekly, monthly, yearly?
Is there a workaround?
Priority Type | Definition | Example |
|---|---|---|
Critical | Critical defects represent severe issues that need immediate attention, potentially halting the system or causing substantial disruption | Alumni/Community Giving - Jarvis is inaccessible and emails (therefore no workaround) |
Major | Major defects represent urgent issues that require prompt resolution as they significantly impact functionality or performance |
|
Minor | Minor defects represent non-urgent issues or minor inconveniences that can be addressed in routine maintenance |
|
Trivial | Trivial defects represent minor issues that have minimal impact on the system or user experience |
|
Stories and Tasks
Here are some considerations that will determine the priority of a story or task.
What are the benefits to users?
Does it benefit all TAP users or is it assisting a very limited number of users?
Is the benefit for an activity that occurs daily, weekly, monthly, annually? The more frequent the activity, the greater the benefit.
Does it support identified TAP strategy or roadmap?
Priority Type | Definition | Example |
|---|---|---|
Must have | Must-have enhancements represent crucial features required for the system's core functionality and user needs |
|
Should have | Should-have enhancements represent important features that add significant value to the system or product |
|
Could have | Could-have enhancements represent features that are desired but not critical for the system's core functionality |
|
Won’t have | Won't-have enhancements represent features that are explicitly decided not to be included in the current version |
|
Jira Fields
Reporter - whoever raised the ticket
Assignee - who’s working on the ticket right now
Priority - for stories and enhancements its MOSCOW. Defects are critical, major, minor
Labels - we use them for calling out hotfixes
Business area - GA, GI, TAP
BA working on - BA assigned
Feature Owner - allows multiple people. The person requesting it. If a team member submits the service portal request PO needs to reach out to confirm with the manager.
T-shirt sizing - see above
Sprint - what sprint number it's in. Only an admin can allocate a ticket to a sprint because it's a company-managed board.
Fix version - tags whatever release it will go out in. Sometimes, tickets must move out of that release because additional testing is required or a defect must be prioritised first. If the ticket is deprioritised, you can remove the fix version altogether.
Due date - is when we've agreed to give you this feature by
Requested date - is the date that the business person has asked for this feature by
Ready for Releases
When a ticket is ready to be released into Production the following should be updated:
Business sign off documented. This should be captured in the comments and should outline who in the business has signed off
The ‘readyforprod’ label added
The ticket should be assigned to the developer pulling the request into the release