Jira Ticket Hierarchy
Summary
Standardizing a Jira Ticket Hierarchy allows all producers of feature requirements and implementation details (product management, engineering leads, and engineers) and consumers of those requirements (support, SRE, docs, marketing) to collaborate on the right level of detail for their job roles.
Description
Jira can often feel like a black hole for tickets. New tickets come from multiple places, such as
Bugs from support or production
Tech debt from engineering
Features and improvements from product and all other departments listed above
Merging these workstreams together using Workstream Merge Points ticket implementers (typically engineering) keep track of and prioritize work, but doesn’t help Downstream Departments (such as SRE, support, and docs) understand features coming down the pipeline at the right level of detail. The docs team needs a different level of detail than the SRE team to support the same features.
Initiatives
Initiatives are collections of epics defining a new product, sub-module, or major direction for the platform.
Executives and Product Management should discuss initiatives quarterly to determine the highest priority major initiatives for the platform.
Once released, sales should read and understand these tickets.
Epics
Epics are the smallest complete collection of user stories for a feature. Epics written by the product team describe the desired future state for part of the product with very few implementation details. Epics should contain the feature's business value (the “why”).
Product Management and engineering leadership (Architects and Tech Leads) should discuss and break down epics monthly to line up work for upcoming sprints.
Once released, documentation and marketing should read and understand these tickets.
User Story
User Stories are the smallest implementable unit of user value. User stories may be written by a team lead or product owner and should all be implementable within a single sprint.
Engineering leadership (Architects and Tech Leads) should break down epics into user stories in anticipation of sprint implementation and discuss these tickets with engineers before implementation begins.
Once released, support engineers and SRE should read and understand these tickets (along with epics).
Sub-Task
Sub-Tasks are implementation detail written and read by only the implementing engineer.
Engineers may create these tickets to help during their implementation. Sub-tasks should not span sprints.
Once released, engineers should only need to read these during debugging or advanced incident response.