Jira — The Core Concepts

What Any Task Tool Must Do laid out the durable job every task tool performs: hold one shared list of work, show its state, and let a team move it from “someone thought of this” to “done.” Jira is one of the oldest and most widely used tools built for that job. This page teaches its core concepts from the ground up — not where the buttons are, but what the moving parts are and why they exist.

A warning before we start, and it holds for every tool page in this part. Jira’s menus, labels, and screens change often, and the exact wording you see will not match this page precisely. As of 2024 the layout and terminology described here were current, but treat the specific menu names as illustrative. What does not change is the underlying model — projects, issues, workflows, boards, backlogs, and a query language. Learn that model and you can find your way around any version.

Projects contain issues

Jira’s whole world is built from two nouns.

A project is a container for a body of related work — usually one team’s work, or one product, or one initiative. It has its own settings, its own members, and its own board. Think of it as the folder that everything else lives inside.

An issue is the atomic unit of work: a single thing to be done. Despite the name, an “issue” is not necessarily a problem — it is Jira’s generic word for a work item. A feature to build, a bug to fix, a chore to finish, a question to answer: each is an issue. Everything you track in Jira is an issue of some type, living inside a project.

PROJECT  "Checkout Redesign"
  ├── issue  PAY-101   Add express checkout
  ├── issue  PAY-102   Fix coupon rounding bug
  ├── issue  PAY-103   Update the receipt email
  └── issue  PAY-104   Research one-click payments

That short prefix on each issue — PAY-101 — is the issue key: the project’s key plus a number. It is how people refer to a specific piece of work in conversation, commit messages, and links. One stable name for one item is exactly the “single source of truth” idea from the previous page, made concrete.

Issue types: a hierarchy of size

Not all work is the same size, so Jira gives issues types, and the main types form a hierarchy from large to small.

• Epic — a large body of work that is too big to finish in one go and is delivered as many smaller pieces. “Redesign the checkout flow” is an epic. It groups related work under one banner.
• Story or Task — a single deliverable that a team can complete in a reasonable stretch of work. A story is typically framed from the user’s point of view (“as a customer I can save my card”); a task is any other unit of work. For our purposes they sit at the same level.
• Sub-task — a slice of a story or task, used when one item naturally breaks into a few steps that different people or days will handle.

Sitting outside that size hierarchy is the bug — a defect, something that is broken and needs fixing. A bug is usually the same size as a story or task; it is a separate type because teams want to count and report on defects separately from new work.

EPIC            Redesign the checkout flow
  ├── STORY     Save a card for next time
  │     ├── SUB-TASK   Add the "save card" checkbox
  │     └── SUB-TASK   Store the token securely
  ├── STORY     One-click repeat purchase
  └── BUG       Coupon total rounds the wrong way

The point of the hierarchy is not bureaucracy — it is zoom. A leader wants to see progress at the epic level (“is the checkout redesign on track?”); a team member wants to see the sub-task in front of them today. One structure serves both by letting each person look at the altitude they need.

Names vary between Jira setups and change over time — some teams add types like “spike” (a piece of research) or “chore” — but the shape is stable: one big grouping type at the top, one working-sized type in the middle, one splitting type below, and a separate defect type off to the side. Learn the shape, not the specific labels your instance happens to use.

The common trap — sub-task sprawl

The most common Jira mess is breaking everything into sub-tasks by reflex. If a story is small enough to finish in a day or two, sub-tasks add clicks and hide the real state behind a tree you have to expand. Use sub-tasks only when a story genuinely splits across people or days. When in doubt, keep the story flat. The tool rewards the smallest structure that keeps the work clear, not the deepest one.

Workflows and statuses: configurable per project

Every issue moves through a series of statuses — the named states that answer “where is this in its journey?” A minimal set is To Do → In Progress → Done. The set of statuses plus the allowed moves between them is called the workflow.

The crucial fact: workflows are configurable, and configured per project. One team’s workflow might be the simple three-status line above. A regulated team’s workflow might be To Do → In Progress → In Review → In QA → Awaiting Approval → Done, with rules about who can make each move and what must be true before an issue advances. Jira lets you model that.

SIMPLE WORKFLOW
  To Do  ──▶  In Progress  ──▶  Done

REGULATED WORKFLOW
  To Do ─▶ In Progress ─▶ In Review ─▶ In QA ─▶ Awaiting Approval ─▶ Done
                              │
                              └─▶ (can send back to In Progress on rejection)

This configurability is Jira’s signature strength and its signature danger. A workflow that mirrors how your team actually works makes the board honest — every column means something real. A workflow copied from someone else, or grown to fifteen statuses because each felt important once, becomes a maze people route around. The rule of thumb: a status earns its place only if someone makes a different decision depending on whether an issue is in it.

How it connects

A status is the visible answer to “how do we know what state this is in?” — one of the plain questions a way of working must answer. Jira does not decide your workflow for you; it faithfully models whatever agreement your team has reached. If your statuses are confusing, the problem is usually an unclear agreement, not the tool. Fix the way of working first, then make the workflow mirror it.

Boards: Scrum versus Kanban

A board is the visual layout of a project’s issues, arranged in columns by status. Jira offers two board styles, and the choice maps directly onto the two ways of working from Part 6.

A Scrum board works in sprints — fixed-length blocks of time (often one or two weeks). The team commits to a set of issues at the start of a sprint, works through them, and starts fresh next sprint. The board shows only the current sprint’s work. This is the tool expression of Scrum’s rhythm of sprints.

A Kanban board works in continuous flow — there are no sprints. Issues move across the board one at a time as capacity frees up, and the team caps how many can sit in each column at once (a work-in-progress limit). This is the tool expression of Kanban: visualize flow, limit work in progress.

SCRUM BOARD  (this sprint only, resets each sprint)
  To Do        In Progress     Done
  ┌──────┐     ┌──────┐        ┌──────┐
  │ PAY- │     │ PAY- │        │ PAY- │
  │ 103  │     │ 101  │        │ 108  │
  └──────┘     └──────┘        └──────┘

KANBAN BOARD  (continuous, WIP limit shown per column)
  To Do        In Progress (3)  In Review (2)   Done
  ┌──────┐     ┌──────┐         ┌──────┐        ┌──────┐
  │ ...  │     │ ...  │         │ ...  │        │ ...  │

Same underlying issues, different lens on them. Choosing between the boards is not really a Jira decision — it is the way-of-working decision from Part 6, and the board simply follows.

A useful way to hold the difference: a Scrum board answers “what did we commit to this cycle, and how far through it are we?”, while a Kanban board answers “what is flowing through the system right now, and where is it piling up?” If your team plans in batches, the Scrum board fits. If work arrives unpredictably and you care most about smooth throughput, the Kanban board fits. Picking the board for a reason you can state is the whole discipline; picking it because it was the default is how teams end up running sprints they never actually plan.

The backlog, sprints, and estimation

The backlog is the ordered list of everything the team might do that is not on the current board — the queue behind the work in progress. It is the same single, prioritized list idea from Scrum: top means “do next,” bottom means “someday, maybe.”

On a Scrum project, planning a sprint means pulling issues off the top of the backlog into the sprint. The backlog is where the priority owner shapes and reorders work; the sprint is where the committed slice lives.

To decide how much fits in a sprint, teams estimate the size of issues. The common unit is the story point — a deliberately rough measure of relative effort and complexity, not hours. An issue estimated at 5 points is understood to be roughly five times the effort of a 1-point issue. Over a few sprints a team learns how many points it typically completes — its velocity — and uses that to plan a realistic next sprint.

The common trap — treating story points as hours

Story points exist precisely so teams can size work without pretending to predict exact hours, which humans are famously bad at. The moment a manager converts “8 points” into “so, 8 hours?” and holds people to it, the estimate stops being an honest signal and becomes a promise nobody can keep. Points are for the team’s own planning — a way to sense whether a sprint is overloaded. They are not a productivity score, and they do not compare across teams. Use them to plan, never to judge.

JQL: a query language for your work

As a project grows to thousands of issues, browsing a board is not enough. Jira answers this with JQL — the Jira Query Language — a way to ask questions of your issues in a structured search, much like a search filter written in words.

A JQL query is a set of conditions. You do not need to memorize the syntax; you need to grasp the idea that your work is queryable data, not just cards on a board.

project = PAY AND status = "In Progress" AND assignee = currentUser()
   → "everything in the Checkout project I'm working on right now"

type = Bug AND status != Done AND priority = High
   → "all open high-priority bugs"

sprint in openSprints() AND labels = payments
   → "payments-labelled work in the current sprint"

Saved queries become filters, and filters feed dashboards and reports. This is what people mean when they say Jira is strong at reporting: because every issue is structured data with a type, status, assignee, and labels, you can slice it any way a question demands. “How many bugs did we close last month?” or “what is still blocking the release?” becomes a query, not a manual count.

The deeper idea is worth naming plainly: your work is data. Every card is a record with fields, and a query language is simply the ability to ask that data questions. You will not always write JQL by hand — Jira offers point-and-click filters too — but understanding that the board is one view of queryable data, rather than the data itself, is what separates people who use Jira from people who merely tick boxes in it.

Components, versions, and labels: extra ways to slice

Three more attributes let you organize issues along axes that cut across the hierarchy.

• Components — named parts of the product (“Checkout,” “Search,” “Billing”). Tagging an issue with a component lets you filter and report by area of the system.
• Versions (sometimes called releases or fix versions) — which planned release an issue belongs to. This lets a team group all the work going out in “v2.4” and track a release’s readiness.
• Labels — free-form tags anyone can add (payments, tech-debt, customer-request). Flexible and fast, but ungoverned: with no rules, labels multiply into near-duplicates (tech-debt, techdebt, tech_debt) and lose their value.

Components and versions are structured and usually managed by a lead; labels are open to everyone. All three exist for the same reason — to give JQL more dimensions to query and report on.

The healthy habit is to keep a small, agreed set of components and versions, and to treat labels with light discipline — a short list the team actually recognizes, reviewed occasionally so the duplicates get merged before they spread. As with statuses, more dimensions are not automatically better; each one earns its place only if someone genuinely queries or reports on it.

What Jira is genuinely for

Here is the honest summary. Jira suits complex, high-volume, or regulated engineering workflows — situations where the configurability is a feature, not a burden. If you need multi-stage approval workflows, defect tracking separated from feature work, cross-team epic rollups, and rich querying over thousands of issues, Jira’s depth pays for itself.

That same depth is overkill for a small team tracking a few dozen simple items. The configurability that makes Jira powerful for a regulated team makes it heavy and click-y for a two-person side project. This is the trade-off the tool-choice page returns to: match the tool’s weight to the work’s complexity, and never adopt depth you do not need.

In practice — where Jira earns its keep

A medical-device company builds software that must pass audits. Every change has to be traceable: who requested it, who reviewed it, who approved it, which release it shipped in, and which requirement it satisfies. A lightweight tool would force them to bolt that structure on by hand. In Jira, a custom workflow enforces the review-and-approve stages, versions track each release, links tie issues to requirements, and JQL produces the audit report on demand. The same setup would crush a small team building a marketing site — but here, the structure is the value.

Try this

Take one real body of work you are involved in — a project at work, a home renovation, planning an event — and model it on paper the way Jira would. Write one epic (the big goal), three to five stories or tasks under it, mark one item as a bug or problem to fix, and give each item a status from a three-column workflow (To Do, In Progress, Done). Then write, in plain words, two questions you would want to ask across all of it (“what is still not started?”, “what is blocked?”). Notice that you have just designed a project, an issue hierarchy, a workflow, and two JQL queries — without touching the tool. That model is the thing Jira stores; the software is only the container.

Reflect

1. In your work, does the epic-to-sub-task hierarchy match how your work naturally breaks down, or would you be forcing your work into it? Where does it fit, and where does it strain?
2. Your team’s workflow is whatever statuses your issues pass through. Are yours honest — does each column represent a state where someone makes a different decision — or are some there out of habit?
3. Would your work fit a Scrum board (fixed sprints) or a Kanban board (continuous flow) better? What does that answer tell you about your real way of working?
4. If you use story points, are they serving your team’s planning, or have they quietly become a productivity score someone watches? What would change if you used them only to plan?
5. Think of a question you regularly answer by manually counting or scrolling (“how many open bugs?”). If your work were structured, queryable data, how much of that manual effort would disappear?

Show reflections

1. Most work has some natural nesting — a goal, its pieces, and occasionally sub-pieces — but not always three clean levels. The useful finding is where the hierarchy strains: if you are inventing epics to satisfy the tool, or drowning in sub-tasks, the structure is fighting your work rather than describing it. Model the work first; adopt only the levels it actually has.
2. The test in the question is the sharp one: a status earns its place only if someone acts differently depending on it. Columns that exist “so we can see it” but drive no decision are just visual clutter. Honest workflows are short; suspicious ones are long. If you cannot name the decision a status enables, it is a candidate to cut.
3. This is really the Part 6 question wearing a tool costume. Fixed, plannable batches of work point toward Scrum; a steady stream of varied, arriving-anytime requests points toward Kanban. If your answer here contradicts the board you currently use, you have found a mismatch between your tool and your actual way of working — worth naming.
4. The honesty test of estimation. If points are a private planning aid the team owns, they are healthy. If anyone outside the team tracks them as output, they have been corrupted into a target, and Goodhart’s law takes over — people inflate estimates to look productive. Reclaiming points as a planning-only signal usually restores their usefulness overnight.
5. Nearly all of it. The value of structured data is that yesterday’s manual count becomes today’s saved query, run in a second and always current. Naming one recurring manual count is naming one report you never have to do by hand again — and it hints at how much of “reporting” is really just querying data you already have.