Jira Issue Organization

Jira Projects

Projects in Jira ("Projects" in the top menu) are containers for issues. These are not what we typically call a project (e.g., large work efforts like "Upgrade Meridian to the latest version"). Instead, these are buckets to organize like issues around systems or applications. So, an effort to "Upgrade Meridian" would be an epic-type issue in the "Meridian" Jira project. All upgrade efforts over the years would go in the one project. Issues (epics, in this case) have start and end dates and go through a todo/in progress/done workflow. Jira Projects, however, do not start, end, or go through a workflow - they solely exist to hold issues.

Jira Issues

Epic Issues

An Epic is a special type of Jira issue that represents a work effort with many related tasks (what we traditionally call a 'small project'). For example, the effort to "Upgrade Meridian to the latest version" would be an epic containing related tasks such as:

Research system requirements
Upgrade software in QA
Run test sets against a new version
Upgrade software in Prod
Perform user validation testing

Work is not typically done against an Epic directly as they are container issues. Epics should have multiple issues contained within them that represent the technical work being done.

Initiative Issues

Initiatives are larger work efforts made up of multiple epics. These epics may exist in one or more Jira projects. For example, there might be Jira projects called "IT Operations" and "Budget App". If there is an initiative to "Upgrade all servers to Windows Server 2016", it could have epics in both of these projects, like this:

Initiative - "Upgrade all servers to Windows Server 2016"
- Epic - "Upgrade rsq-iis01 to Windows Server 2016" (this would reside in the IT Operations project)
  - Task - "Identify all applications on rsq-iis01"
  - Task - "Upgrade apps on rsq-iis01 to version compatible with Windows Server 2016"
  - ...
- Epic - "Upgrade Budget App to be compatible with Windows 2016" (this would reside in the Budget App project)
  - Task - "Upgrade to .NET 4.5"
  - Task - "Upgrade Telerik controls"
  - ...

Then, looking at this initiative, we can drill down to all of the epics and tasks required to get the entire upgrade initiative completed.

Work is not typically done against an Initiative directly as they are container issues.

Service Desk Requests

Service Desk requests are represented by issues in the IT Service Desk (ITSD) project. ITSD tickets are the only Jira issues that customers can see (through the Service Desk portal at http://help.sacsewer.com/). The ITSD ticket is for customer status sharing and communication. For some service desk requests, when the resolution is quick and only requires one person, this is the only ticket that is required (i.e., granting VPN access, changing folder permissions, resetting passwords, etc.). For larger or more complex issues, linked remediation issues are often created to track more detailed/technical work. The remediation ticket is for tracking the technical work done to resolve the request. The ITSD ticket is the only one a customer can see, and they are intended to remain open until the customer request is resolved.

Remediation Issues

Remediation issues are solely defined by issue links. They are not a specific issue type. They are issues (of any type) that are linked to ITSD requests using the remediation link. For example, if a customer reports a bug in an application, there will be two issues in Jira:

The original ITSD issue created by the customer
A linked issue assigned to the IT staff member doing the technical work

The two issues are linked using Jira issue links. The first is remediated by the second, and the second remediates the first.

The ITSD request would have a link similar to this:

The remediation ticket (assigned to the developer in this example) would have a link similar to this:

Tasks and other Issue Types

Not all the work we do is a small project (Epic) or large project (Initiative), sometimes you just need to work on a simple task or fix a bug. The other issue types are for just that.

Sub-tasks

Sub-tasks are generally optional and not required. If you are assigned an issue, you can use sub-tasks to break down the sub-tasks required to get the parent tasks complete. You can also use them to assign part of the task to someone else.

An issue with sub-tasks should not be resolved until all of the sub-tasks are resolved. In other words, an issue should not be resolved if it has open sub-tasks.

Here's a good overview from the Atlassian Agile Coach on structures that help agile teams gracefully manage scope and structure work:

https://www.atlassian.com/agile/project-management/epics-stories-themes