Why this matters
If you’ve logged into Jira recently, you’ve probably noticed:
“Issues” are now called “Work Items.”
It’s more than a name change. It’s Atlassian’s way of modernising Jira around real-world work management – where not everything is a bug or story, but all work still needs to be connected, traceable, and visible across teams.
Most teams treat Jira configuration as a technical task. At Quirk, we see it differently.
Jira isn’t just a tool – it’s the nervous system of your organisation.
The way you define work item types and links determines whether your team spend time doing the work FOR the customer, or spend more time arguing about dependencies and metrics.
What are Jira Work Items (formerly Issues)?
Jira Work Items represent the individual pieces of work your teams track – from ideas to delivery tasks, incidents, and outcomes.
Each work item is categorised by its type, which tells Jira how to handle it, what fields it needs, and how it connects to others.
|
Work Item Type |
Purpose |
Example |
|---|---|---|
|
Epic |
Large initiative or feature set |
“Customer Onboarding Experience” |
|
Story / Task |
Deliverable that provides value |
“Add video walkthrough to onboarding” |
|
Sub-task |
Smaller dependent unit of work |
“Record voiceover for walkthrough” |
|
Bug |
Defect or issue to be fixed |
“Video doesn’t autoplay on mobile” |
|
Change / Incident / Problem (ITSM) |
Service-specific operational items |
“Database latency issue” |
Custom work item types let you model how your organisation really operates – marketing campaigns, risk reviews, compliance activities, or R&D experiments.
That’s where Jira stops being a tracker and starts becoming a connected system of work.
Jira Work Item Type Hierarchy
Hierarchy defines how work connects – and who can see what at each level.
Default hierarchy:
Epic → Story/Task → Sub-task
In Jira Premium (Advanced Roadmaps), you can extend it:
Initiative → Epic → Story → Sub-taskEach layer adds clarity for a different audience:
-
Executives: See Initiatives rolling up to portfolio outcomes
-
Managers: Track Epics and their progress
-
Teams: Deliver Stories and Sub-tasks
A clean hierarchy makes work visible, connected, and decision-ready – across teams and departments, not just within a single board. As your organization becomes more complex, this shared language of hierarchy will make collaboration and reporting possible.
Jira Work Item Links Explained
While hierarchy connects parent-child relationships, work item links show relationships across projects, teams, and contexts.
|
Link Type |
Meaning |
Example |
|---|---|---|
|
Blocks / Is blocked by |
One work item prevents another from progressing |
“Backend API” blocks “Frontend integration” |
|
Relates to |
General association |
“Email template” relates to “Campaign setup” |
|
Duplicates / Is duplicated by |
Avoids duplicate work |
Two teams log same request |
|
Clones / Is cloned by |
Replicates structure for reuse |
“Quarterly campaign brief” cloned for Q2 |
|
Causes / Is caused by |
Tracks causal dependencies |
“Missing auth token” causes “Login failure” |
Used properly, work item links reveal how work flows – and where it gets stuck. When issue links are created properly, you can then use Jira Apps like Dependency Mapper for Jira to see where work is expected to slow down or become stuck. Identifying and having a conversation about dependencies before the work starts is an incredible way to set your teams up for success and avoid surprises mid-sprint.
Configuring and Editing Work Item Types
To create or modify work item types in Jira:
-
Go to Settings → Issues → Issue Types (or Work Item Types in new UI)
-
Add or edit an existing type
-
Assign each to an Issue Type Scheme
-
Map that scheme to the right projects
-
Use consistent names and icons across teams
💡 Quirk tip: Don’t let every team invent their own types. It creates false confidence – “Done” will mean ten different things.
Jira Work Item Templates: Speed with Structure
Templates make work predictable, repeatable, and reportable.
You can use:
-
Native field defaults for descriptions, priorities, or labels
-
Marketplace apps like Quirk’s Board Rewind for Jira
-
Automation rules that clone from a “master” item
Removing or Cleaning Up Jira Work Items
You can delete individual work items from the More → Delete menu, or bulk delete via Advanced Search – but proceed with caution.
At Quirk, our rule is simple: don’t delete the evidence.
Archive or transition it instead. Historical data reveals delivery patterns, dependencies, and anti-patterns that can’t be rebuilt later. This data is valuable for improving how work is done in future iterations.
TL;DR – Jira Work Items Cheat Sheet
|
Concept |
Purpose |
Quirk Tip |
|---|---|---|
|
Work Item Type |
Defines the kind of work |
Standardise across projects |
|
Hierarchy |
Structures work levels |
Extend for exec visibility |
|
Work Item Link |
Shows related work |
Use for dependency mapping |
|
Template |
Creates consistency |
Automate from reference issues |
|
Remove / Archive |
Cleans old data |
Never delete – label instead |
Frequently Asked Questions about Jira Work Item Links
What are Jira work items vs issues?
They’re the same concept. Atlassian is shifting terminology from “Issues” to “Work Items.” Functionality stays the same; the new name better reflects modern work management.
What are the main Jira work item (issue) types?
Common types: Epic, Story, Task, Sub-task, Bug. In ITSM projects: Incident, Problem, Change, Request. You can add custom types to fit your business model.
How does the Jira work item (issue) type hierarchy work?
Default: Epic → Story/Task → Sub-task. With Advanced Roadmaps (Jira Premium), extend to Initiative → Epic → Story → Sub-task for portfolio views.
When should I use work item links vs hierarchy?
Use hierarchy for parent/child structure (work breakdown). Use links (Blocks, Relates, Duplicates, Clones, Causes) to show cross-team dependencies and relationships.
How do I edit a work item (issue) type in Jira?
Go to Settings → Issues → Issue types (or Work item types in new UI). Edit fields, screens, and workflows; then ensure the Issue Type Scheme is mapped to the right projects.
Can I convert a work item from one type to another (e.g., Task → Story)?
Yes. Open the item → More (⋯) → Convert to…. Check field mappings and workflow status to avoid data loss.
What’s the best way to standardise work item templates?
Use description templates, automation cloning, or a templates app to prefill fields, checklists, and labels. This improves data quality and reporting consistency.
How do I create dependency visibility without extra admin?
Define a small, standard set of link types (e.g., Blocks/Blocked by, Relates to), and add simple rules: e.g., if Blocked by exists, surface it on boards/dashboards. Keep it lightweight and automated.
Should I delete work items to keep things clean?
Prefer archive or transition to a “Won’t Do/Cancelled/Archived” status. Deleting removes historical signals that help find bottlenecks and anti-patterns later.
Why do my reports look inconsistent across projects?
Usually because types, statuses, and fields aren’t standardized. Align your type scheme, status categories, and required fields across projects, then rebuild dashboards.
How do work item templates differ from subtasks?
Templates define structure (fields/checklists) for any work item. Subtasks are child items in the hierarchy used to break down a Story/Task.
What’s the fastest way to roll out a consistent Jira work item model?
Start with a global work item scheme, a minimal status set, a linking policy, and a template pack. Pilot with two teams, iterate, then scale.
