A Jira work item is the term Jira now uses for what was previously called an “issue.” It represents any piece of work — such as a task, story, bug, or epic — that your team tracks through a workflow. The rename rolled out across Jira Cloud in stages through 2025 and into early 2026; if you’re on Jira Cloud today, “work item” is the standard term you’ll see everywhere in the product. Everything else — how work items are created, typed, and organized into a hierarchy — works exactly as before.
This guide covers what a work item is, the difference between work item types and work item hierarchy, and — because naming things correctly is only half the job — how hierarchy actually affects the metrics you pull out of Jira.
What Is a Jira Work Item?
A work item carries a status, an assignee, a summary, comments, and a history — it’s the thing that moves across your board from “To Do” to “Done,” whatever type of work it represents.
Atlassian began phasing out “issue” in favor of “work” as the collective term for everything tracked in Jira back in 2025 — a separate effort from (and one that predates) the “Project → Space” rename. By now, the rollout has largely run its course: “work item” is the term you’ll find across Jira’s current interface, documentation, and release notes. If people on your team still say “issue” out of habit, that’s normal — it doesn’t mean anything is misconfigured. Either way, the change was always cosmetic: work items keep the same fields, workflows, permissions, and underlying data, and JQL and integrations built around “issue” terminology continue to work.
For teams, the practical takeaway is small: update your internal documentation and onboarding materials to say “work item,” and expect a short adjustment period where colleagues use “issue” and “work item” interchangeably. Nothing about your configuration needs to change.
Jira Work Item Types
A work item type defines what kind of work an item represents and, in many cases, how it behaves on your board and in reporting. Jira ships with a set of default types:
- Task — a standalone piece of work with no inherent hierarchy assumption.
- Bug — a defect that needs fixing.
- Story — a user-facing requirement, typically part of a larger initiative.
- Epic — a large body of work broken down into multiple stories or tasks.
- Sub-task — a smaller step nested inside a task, story, or bug.
Every work item type belongs to one of two categories: standard (Task, Bug, Story, Epic, and any custom type you create, including higher-level types like Initiative or Feature) or sub-task, which always nests underneath a standard-level item. A type’s category is separate from its position in the hierarchy — Initiative and Epic are both standard types; they just sit at different hierarchy levels (more on that below).
A work type scheme determines which work item types are available within a given space. Different spaces can run different schemes — so a software team’s space can offer Story, Bug, and Epic, while an HR or marketing space in the same site can offer a completely different set of types that match how that team actually talks about its work, without either team affecting the other’s setup.
Jira admins can also create custom work item types to match a team’s actual vocabulary instead of forcing everything into generic Task/Story labels — for example, Idea, Incident, or Change Request, depending on what the team actually tracks.
Jira Work Item Hierarchy
Work item hierarchy determines how types relate to each other — which ones can be a parent, and which ones must be a child. By default, Jira uses three hierarchy levels:
| Level | Default name | Typical scope |
| Level 1 | Epic | Large initiative, spans multiple sprints |
| Level 0 | Story / Task / Bug | Standard, sprint-sized work |
| Level -1 | Sub-task | A step inside a standard work item |
On Jira Cloud Premium and Enterprise plans, admins can extend this structure with custom hierarchy levels above Epic — commonly Initiative or Solution — to model larger programs of work, most often for teams following frameworks like SAFe. A custom setup can end up looking like this:
A few practical constraints worth knowing before you touch hierarchy settings:
- Hierarchy configuration is global — it applies across all company-managed spaces on your site, not just one team.
- In the current Jira Cloud implementation, Epic remains fixed at Level 1. You cannot insert a new level directly between Epic and standard-level work items. The common workaround is renaming Epic to something like “Feature,” then creating a new work item type called “Epic” one level above it.
- Changing the hierarchy structure can break existing parent-child relationships. Jira will warn you and ask for confirmation before applying changes that affect existing links — and those changes generally can’t be undone.
If you’re planning a hierarchy change, do it deliberately, communicate it to every space that shares the scheme, and expect to re-link some items afterward.
Why Hierarchy and Work Item Types Matter for Reporting
Hierarchy is an organizational tool — but it doesn’t measure how work actually flows through your process. That’s because time is spent by child work items, not by the parent work item sitting above them. An Epic can look perfectly on-track from the outside while the Stories underneath it quietly pile up with wait time nobody’s looking at.
Here’s the problem in practice. An Epic shows a two-week span from creation to completion. That looks fine on a roadmap. But that Epic doesn’t actually “spend” time in a status — its child work items do. If three of those Stories each sat in “Waiting for Review” for two days, that’s six days of the Epic’s timeline that a top-level view will never show you. The parent work item just shows a start date and an end date; everything that happened underneath it — every bottleneck, every hand-off delay — is invisible unless you look one level down.
This is precisely where the standard rollup you get from Epic panels or roadmap views runs out of answers, and where time in status data at the child work item level becomes necessary.
See Where the Time Actually Went Across Your Work Item Hierarchy
Time in Status shows the total time a work item spent in every status: In Progress, Review, Waiting for QA. Scope the breakdown to a specific Epic (or a Sprint, or a Project) using the standard report filters, and the picture changes completely: instead of “this Epic took two weeks,” you get “this Epic took two weeks, and four of those days were spent waiting on QA across three different Stories underneath it.”
Isolating patterns by work item type: You can narrow any report to a specific type using the built-in JQL filter (for example, issuetype = Bug). That’s enough to compare, say, average cycle time for Bugs against Stories, or to check whether Sub-tasks are silently accumulating wait time that never shows up in the parent Story’s headline duration.
The broader point is that work item types and hierarchy define the structure of your work. They don’t, by themselves, tell you where time is actually going. For that, you need to look at status duration at the level where the work is actually happening — not just at the summary level where it gets reported upward.
FAQ
Is a “work item” different from an “issue”? No — it’s the same object with a new name. Atlassian renamed “issue” to “work item” in Jira Cloud; workflows, fields, permissions, and API behavior are unchanged.
Can I add a custom hierarchy level in Jira? Yes, but only on Jira Cloud Premium and Enterprise plans, and only above the Epic level (for example, adding Initiative or Solution). In the current Jira Cloud implementation, you cannot insert a level between Epic and standard work items directly.
What happens to parent-child links if I change the hierarchy? Existing relationships can break if you move work item types between levels. Jira will calculate the impact and ask you to confirm before applying the change, and the change cannot be undone afterward.
Does changing hierarchy affect Time in Status reports? No — Time in Status reads the Epic and Parent fields as they currently exist on your work items, so you can get time in status reports regardless of how your hierarchy levels are configured above them.
Bottom Line
A work item is simply what Jira used to call an issue — nothing to reconfigure there. Work item types and hierarchy give your work a shape: what kind of thing it is, and what it belongs to. But that shape only tells you where work sits, not how long it actually takes. To see the real picture, you need status-level time data rolled up underneath the Epic or Parent — not just the headline start and end dates at the top.