What is Jira: a fair look at Atlassian's issue tracker

TL;DR. Jira is Atlassian’s issue tracker — the ticket-by-ticket system most engineering teams use to plan, track, and ship work. It launched in 2002, is still the category default in 2026, and now ships AI agents that can own tickets the same way humans do. This post walks through what Jira actually is, how it works, what it does well, where it struggles, and the part most explainers skip: Jira is an issue tracker, not a wiki, and the wiki next to your Jira is a separate question.

Most posts about Jira are written either by Atlassian or by the consultancy that wants to charge you to configure it. This one is written by neither. Jira is the incumbent issue tracker, and like most incumbents in software, it is more right than its reputation gives it credit for. It is also one of two products in the Atlassian-suite story — the other being Confluence, the wiki — and the post nobody seems to write is the one that names the line between them.

We’ll cover what Jira actually is, how the issues-projects- boards-workflows mental model works, the three Jira products, the Atlassian Intelligence and AI agents story, where Jira is genuinely strong, where it struggles, and the test you can run to figure out whether your team’s Jira pain is the Jira or the documentation surface next to the Jira.

What Jira actually is

Jira is an issue tracker. The full sentence is Jira is a hosted (and on-premise / Data Center) issue-and-project- tracking system made by Atlassian, sold as the central work- management surface of the Atlassian suite, with deep integration into Confluence, Bitbucket, and the rest of the Atlassian catalogue, a large marketplace ecosystem on top, and — since 2025 — first-class AI agents that can own tickets alongside humans. The short sentence does most of the work; the long sentence explains why Jira is still the default twenty-four years in.

Atlassian shipped Jira in 2002, when the issue tracker category was small and mostly self-hosted Bugzilla. The name comes from Gojira, the Japanese for Godzilla — the inside joke being that the team built Jira because they were tired of Bugzilla. Twenty-four years later, Jira is the category default. Most teams that ship software at any scale either use Jira, used to use Jira, or are currently running an export from Jira to something they hope will be faster. That category position is the entire backdrop of this post.

For the broader wiki / documentation half of the Atlassian story, see our Confluence explainer and the Confluence vs Jira write-up — the pairing is most of the answer to why is the Atlassian suite still everywhere.

How Jira works

The mental model is small and load-bearing: issues live in projects, projects have workflows, workflows are visualised on boards. Almost every Jira question collapses to one of those four layers.

Issues. The unit of work. A Jira issue is a single trackable thing — a bug, a feature request, a task, a story, a sub-task. Each issue has a type, a status, an assignee, a reporter, a priority, fields you can customise without end, and an audit trail of every state change anyone made to it. The issue is the product. Every other Jira surface is a way of looking at issues differently.

Projects. The unit of organisation. A project is a container of related issues — Backend, Mobile, Customer Support — with its own permissions, its own workflow, its own issue types, and its own board. Atlassian splits projects into team-managed (lighter, configured by the team) and company- managed (heavier, configured centrally), and the choice between those two has consequences that compound over years.

Workflows. The unit of process. A Jira workflow is the state machine an issue passes through — To Do → In Progress → In Review → Done, give or take twelve states and four optional gates. The default workflow is sensible. The customised workflow your team will end up with after eighteen months is the part Atlassian-partner consultancies make their money on.

Boards. The unit of looking. A board is a visual of issues in flight — kanban (columns by status), scrum (sprints with a backlog), or one of several plan / timeline views. Boards are shared across the team; the board is where standup happens for most engineering teams running Jira.

The official explainer with screenshots and the onboarding flow lives on Atlassian’s Jira product page; we are not going to be the post that re-types that.

The three Jira products

Jira is now three products in a trench coat, and the SERP universally undercovers the distinction.

Jira Software is the default — jira software in the CSV, the agile-development product, the one engineering teams mean when they say Jira. Issues, sprints, boards, velocity. The product the rest of the explainer covers.
Jira Service Management (JSM) is the IT-and-customer- support variant. Tickets from customers and employees come in through a portal; SLAs and queues and approval workflows run on top. JSM grew out of Jira Service Desk a few years back and is now most of the way to being a standalone product with shared plumbing.
Jira Align (now mostly rebranded under Jira Premium / Enterprise’s portfolio features) is the enterprise- portfolio variant — the Jira for the org chart above the engineering org chart product. Strategy, OKRs, multi-team programs. Different audience, different pricing.

Most posts you find about what is Jira mean Jira Software. Most procurement conversations about do we need Jira are about JSM. Knowing which one is being discussed saves a meeting.

Atlassian Intelligence and AI agents

Jira’s AI story is the part that has changed the most recently. Atlassian Intelligence — Atlassian’s collection of AI features built into Jira, Confluence, and JSM — has been shipping since 2023; in February 2026 Atlassian announced that Jira now supports AI agents as first-class issue owners, meaning agents can be assigned tickets, run multi-step actions on them, and report progress back the same way a human assignee would.

The features are genuinely interesting. Agents in Jira can draft tickets from a Slack thread, triage incoming bugs, update statuses based on linked pull requests, and (with guard-rails) close tickets that no longer need a human. They are also gated to the paid tiers — Standard and above — with the deeper agent surfaces concentrated on Premium and Enterprise. The product is real; the packaging is the upsell.

Lord Circuitrix, our Lord Circuitrix, has issued exactly one opinion on this: “The agent is the ticket; the ticket is the agent; the wiki is still a wiki.” Signed L.C., posted to the canon decision log without further explanation. We are not going to argue with Lord Circuitrix.

What Jira does well

Honest section. Things Jira is genuinely good at, with no caveats.

Issue tracking depth. A Jira issue is a deeply-featured primitive — typed fields, links to other issues, attachments, inline comments with mentions, version history, time tracking, custom screens, custom workflows. Twenty-four years of feature accumulation, mostly in the right places.
Reporting. Sprint velocity, burndown, cumulative flow, control charts, lead/cycle time, custom JQL dashboards. Jira reports the things engineering managers learn to ask about, and the reports are reliable across teams of meaningfully different shapes.
JQL — Jira Query Language. JQL is one of the best-aged features in the product. Status changed to Done by currentUser() during the last week and project = “Mobile” is the kind of query you can teach a new manager in five minutes and they will use it for a decade.
Permissions. Project permissions, issue-level security, audit logs, role-based access for both internal and external users (JSM). Atlassian-style permissions are not the most fun to configure; they are competent across enterprise shapes.
Marketplace ecosystem. Twenty years of paid and free apps built on the Jira API. If you need the burndown that excludes weekends and the Tuesday all-hands, somebody has built it.
The Confluence pairing. Already covered in our Confluence explainer — the Jira-and- Confluence loop (issues link to docs, docs embed issue lists) is most of the reason Confluence is still the default wiki in 2026. The pairing is the moat for both products.
It exists everywhere. Like Confluence, Jira is the tool most engineering orgs already have. The new engineer already knows Jira. The product manager already has Jira open. We already have Jira is the most-cited reason to stay on Jira, and it is not an unreasonable reason.

Where Jira falls short

Equally honest section. Things Jira does badly, with the same lack of caveats.

Speed. Jira’s page loads on large workspaces are the category’s most-complained-about characteristic. A board with hundreds of cards and a custom filter can take seconds to render. Atlassian has shipped meaningful speed work recently and the gap has narrowed; the clicking and waiting shape is still recognisable to anyone who used Jira in 2018 and 2024 and noticed they were doing the same thing.
Configuration sprawl. Team-managed projects start simple and stay simple. Company-managed projects accumulate custom fields, screens, workflows, and permission schemes until the configuration is itself a knowledge-management problem. The Jira admin role is a real job in most orgs running Atlassian at scale, and the reason it exists is that the configuration surface compounded faster than the documentation surface kept up.
Mobile. The Jira mobile app is functional for triage and status updates; it is rough for the deeper work most engineering teams do in Jira. Most teams stop trying on mobile after a sprint.
Search outside JQL. The search box on top of Jira is improving. Find me the bug Patches filed about the doughnut is still more reliably solved by remembering the ticket number than by typing the words. JQL is the actual search interface; the search box is an aspiration.
Pricing past 100 users. Jira’s Free tier is genuinely generous (up to 10 users). The Standard tier is reasonable per-user. Past a certain size the picture changes — Premium for the AI features your team wants is meaningfully more, and Data Center is its own price class. The cost trajectory is the thing most teams over a hundred users eventually notice.
The wiki next door. This is the one most teams confuse with a Jira problem. Confluence is the wiki most Jira teams also run, and Confluence is slower than Jira, by some distance. The slow wiki next to a fast(ish) issue tracker is the part of the suite teams quietly leave first. The Jira isn’t the problem; the wiki is. (See the next section.)

An issue tracker is not a wiki

This is the opinion section, and it’s the one that explains half the Jira frustration posts on the internet.

An issue tracker is not a wiki. Issues are short-lived, state-bearing, owned by exactly one person, optimised for flow. Wiki pages are long-lived, mostly-stateless, owned by nobody in particular, optimised for retrieval. Jira is a genuinely good issue tracker. It is also not a wiki, and the team that tries to put runbooks, decision records, postmortems, or onboarding docs into a Jira project will end up with a Jira project that doesn’t work as either thing. The Atlassian answer to that is Confluence next to Jira; the Jira-and- Confluence loop exists because Atlassian noticed this twenty years ago.

The honest version is: two tools, one team — the difference between a doc and a ticket. Most engineering teams need both. The interesting question is which of the two is the bottleneck. For most teams the answer is the wiki: Jira is fine, Confluence is slow, the docs nobody can find are the docs nobody reads. Sub-second loads. Keyboard-first. The ten-minute Confluence import into Raccoon Page exists for exactly that case — fix the wiki, leave the Jira. (See the Confluence vs Jira write-up for the longer treatment.)

When to stay on Jira and when to leave

The decision tree, briefly, with one important asterisk: most teams should stay on Jira. The exit ramps are narrower than people think.

Stay on Jira if:

You ship software and the issue-tracking surface is doing real work — sprints, board, JQL reports, deeply-customised workflows.
Your team is on the Atlassian suite generally — Jira, Confluence, Bitbucket — and the integration loop is real.
Your engineering manager has built reports on top of JQL that the team uses weekly.
The team has standardised on the Jira mental model and switching tracker would cost more than the upgrade.

Consider leaving Jira if:

Your team has switched off the Atlassian suite generally — GitHub instead of Bitbucket, Slack instead of Atlassian comms, a different wiki — and Jira is the last Atlassian tool standing.
Your team has fewer than 15 engineers and the configuration sprawl is producing more meetings than tickets.
Your team’s actual work doesn’t fit Jira’s project → sprint → board shape — research orgs, design teams, content ops. Linear, Shortcut, Notion’s project view, or even a shared spreadsheet may be the better fit.
You are paying Premium for the AI agent features and the cost-to-value math has stopped working.

The much more common case: your Jira is fine; your wiki is what hurts. The signal: are your engineers’ decision records and postmortems sitting in a Google Doc or in Notion because the Confluence next to your Jira is slow? If yes, the migration that’s actually overdue is the wiki — not the issue tracker. See the Confluence to Raccoon Page import and the Notion to Raccoon Page import for the two most common paths off the documentation surface while keeping the tracker.

For the broader buying-side frame on top of either choice, the knowledge management software guide is the companion read; for the head-to-head between Jira and Confluence in the same suite, see Confluence vs Jira.

Things people actually ask

What does Jira mean? The name Jira is short for Gojira, the Japanese for Godzilla. The inside joke is that Atlassian built Jira because they were tired of Bugzilla. The name has no formal expansion — it is not an acronym, despite a generation of teams who assumed it must be.

What is Jira used for? Issue tracking and agile project management — bugs, features, tasks, stories, sub-tasks moved through a workflow visualised on a board. Jira software (the most-used variant) is the engineering project tracker most software teams use. Jira Service Management is the IT / customer-support variant. Jira (the brand) covers both.

What’s the difference between Jira and Confluence? Jira is an issue tracker — work in flight, tickets, sprints, boards. Confluence is a wiki — documentation, decisions, runbooks. They share an Atlassian login, a permissions system, and a deep cross-link mechanism. Most Atlassian-suite teams use both, and the Jira-and-Confluence loop is what makes the suite stick. Long-form treatment: our Confluence vs Jira write-up.

What is Jira and Confluence together? The Atlassian suite’s two flagship products. Jira tracks the work; Confluence documents what the work was, why, and what got decided. Jira and Confluence integration — the official phrasing for the deep cross-link mechanism — means a Jira ticket can embed a Confluence page section, and a Confluence page can render a live list of Jira issues. The pairing earns Atlassian most of its enterprise revenue.

Is Jira free? Yes for small teams. Jira’s Free tier supports up to ten users, with the core issue-tracking, board, and JQL features. Past ten users, Standard, Premium, and Enterprise tiers apply, billed per user per month. Atlassian’s pricing page is the authoritative source — the numbers move enough that we are not going to quote them in a post that ships once.

Is Jira good for non-engineering teams? Yes, with caveats. Jira Work Management (now folded into Jira’s broader plans) is Atlassian’s pitch for marketing, HR, finance, and operations teams running on Jira. The strengths (reporting, JQL, workflow customisation) carry over; the mental model — every unit of work is an issue with a status — fits some non-engineering work and feels heavy on others. Trial it with a real workflow before standardising the org.

Where is Jira documentation kept? Two places, depending on what you mean. Atlassian’s documentation — the official help docs for the product — lives on support.atlassian.com and confluence.atlassian.com. Your team’s Jira documentation — runbooks, decision records, how-we-use-Jira — lives wherever your team’s wiki lives, which in Atlassian-suite shops is usually Confluence. Jira documentation searches mostly resolve to Atlassian’s official docs.

How do I migrate off Jira? Atlassian supports CSV / JSON export for issues, plus a more involved Data Center / Cloud migration toolchain for whole workspaces. Modern issue trackers (Linear, Shortcut, GitHub Issues for some teams) ship Jira importers. The honest answer: most teams shouldn’t migrate off Jira; the issue tracker is fine. The migration that’s usually overdue is the wiki next to your Jira, not the Jira itself. See the Confluence to Raccoon Page importer if that’s your case.

Is Jira a wiki? No. Jira is an issue tracker. The Atlassian wiki product is Confluence. Confusing the two is the single most common mistake teams make when they decide they want to put everything in Jira. Jira pages don’t exist; Jira issues do. For the wiki side of the Atlassian story, see our Confluence explainer.

Jira is the issue tracker most engineering teams have. Most of those teams should stay on it. The much more common move is not leaving Jira but fixing the wiki next to your Jira — the slow Confluence space full of runbooks nobody can find on the first search. If that’s where your team is, the ten-minute Confluence import is the shortest path to a wiki your engineers will actually open before opening Slack. Raccoon Page Free is three users, one space, one hundred pages, no card — enough to find out.