Atlassian's issue and project tracker for software teams, now with Atlassian Intelligence for drafting issues and summarizing work.
Last updated
Jira is the tool people complain about while renewing it, and both halves of that sentence are informative. The complaints are real and they are mostly accurate. The renewals are also rational, because the organisations that keep paying are usually the ones where the alternative is not a lighter tracker but an inability to answer a question someone external is entitled to ask.
So this page does not argue that Jira is good or bad. It argues that Jira is the correct answer to one specific condition — a process you did not get to design — and the wrong answer to almost everything else.
The word gets thrown around without content, so here is the content. Jira is heavy in four distinguishable ways, and only some of them apply to any given installation.
It is heavy at the interface: more fields, more screens, more clicks between intending to file something and having filed it. It is heavy at the data model: a project carries workflow schemes, screen schemes, field configurations, permission schemes and notification schemes, each of which can be shared across projects or not. It is heavy at the process layer, because everything the data model allows, some team has turned on. And it is heavy administratively, because all of the above has to be maintained by a person as teams reorganise.
A small team that creates one project and never touches a scheme experiences almost none of this. A team that joins a company with six years of accumulated configuration experiences all of it on day one. When someone says Jira is slow and bloated, ask which of the four they mean, because two of them are the vendor's fault and two of them are the previous administrator's.
This is the cost people forget to budget. Configurability is not free capability; it is capability that requires a maintainer. In practice that means a named person — an internal admin, a platform team, or a consultant on retainer — who owns workflows, permissions and the field taxonomy, and who says no to requests that would make the instance worse.
Instances without that person degrade in a recognisable way. Required fields accumulate because someone once wanted a report. Workflow states multiply until nobody can explain the difference between two of them. Automation rules fire in unexpected combinations. None of this is a defect in the software; it is what happens to a configurable system with no owner, and it is the single best predictor of whether a team will describe Jira as powerful or as a swamp.
Jira is the right tool when the workflow is specified by someone who is not on your team and the specification has consequences. Regulated development where a change has to show review, approval and test evidence in a fixed order. Safety-relevant engineering where traceability from requirement to implementation to verification has to be reconstructable years later. Organisations under audit obligations where "we followed the process" has to be demonstrated rather than asserted. Customer contracts that dictate escalation paths and response handling.
In every one of those cases, the ability to enforce a workflow — to make a transition impossible unless conditions are met, and to record who did what and when — is the entire purchase. Lighter trackers do not merely make this harder; most of them have deliberately declined to build it, because enforcement is exactly the weight they were trying to shed.
Jira sits inside Atlassian's other products and a large third-party marketplace, and this is genuinely useful: requirements written in Confluence that link both ways, code branches in Bitbucket that attach to issues, and marketplace apps that cover gaps the base product leaves.
Be honest about the second effect, though. Marketplace apps become load-bearing quietly. A team adds one for time reporting, another for a specific chart an executive likes, a third for test management, and eighteen months later a migration proposal has to account for four vendors rather than one. Track which apps are load-bearing, because that list is your actual switching cost, not the issue export.
Getting issues out of Jira is straightforward. Getting the process out is not. Workflows, permission schemes, automation rules and the reports built on top of custom fields do not have equivalents in a tool that deliberately lacks those concepts, so a migration to something lighter is usually a process redesign wearing a migration's clothes.
The same applies in reverse, which is the part teams underestimate when they consolidate onto Jira. Importing another tracker's issues is easy; deciding how its conventions map onto schemes is where the weeks go. Budget the design work explicitly in either direction and the project stops surprising people.
Assisted issue drafting, summarisation and natural-language queries are now present across this entire category at a broadly similar level, so they do not distinguish Jira from anything else on this list. What is worth checking before planning around them is which tier they sit in, since that placement has been revised more than once and a feature you assumed was included may sit a plan above where you are.
The AI capability that would actually matter here is different from what is generally shipped: not drafting issues faster, but reading six years of accumulated configuration and telling you which of it is dead. Nobody has solved that, and it is the problem large instances actually have.
Pick Linear when your team owns its own process and nobody outside it needs to inspect the procedure. You are trading enforcement for speed, and if there is nothing to enforce, the trade is free.
Pick Monday when the work is not software. Marketing calendars, client delivery and operations queues can be modelled in Jira, and the result is always a worse version of a tool built for that audience, maintained by an engineer who resents it.
Pick Asana when the reporting audience is executive rather than operational — when the recurring question is how a portfolio of initiatives is tracking across departments, not what happened to a specific ticket. Jira can produce that view with enough configuration, which is precisely the problem. ClickUp is the middle option for organisations that want one system for both and will accept interface density in exchange.
And do not pick Jira because it is what everyone uses. That reasoning is how instances acquire their first thousand unnecessary fields.
Regulated, safety-relevant or contractually-governed work where transitions must be gated and the audit trail has to be reconstructable later. This is the case where Jira's weight is the product rather than a side effect, and where lighter trackers are not a cheaper option but a non-option.
Dependency mapping, cross-project hierarchies and roll-up views for organisations where one initiative touches several groups with different workflows. The value comes from those groups not having to share a process, which is exactly what an opinionated tracker refuses to allow.
Requests arriving from outside engineering with response expectations, escalation paths and queue ownership attached. Enforcement and recording matter more than interface speed here, and this is often the workload that justifies the instance for the rest of the company.
When several groups arrive with incompatible conventions, a tool that can express all of them without forcing one team's process onto another is the pragmatic choice. Plan for the mapping design to take longer than the data import, because it always does.
Jira has four tiers: Free (up to 10 users, scrum/kanban boards, agile reporting, custom workflows, 2GB storage), Standard (~$7.91/user/mo, more scale and permissions), Premium (~$14.54/user/mo), and Enterprise (custom). Two structural points matter more than the per-seat figure. First, the AI features and the advanced planning views sit in the upper tiers rather than the lower ones, so check which tier carries the specific capability you are planning around before you budget. Second, marketplace apps are billed separately and scale with your user count, so an instance that depends on several of them can cost meaningfully more than the plan price suggests. Atlassian revises tier contents and self-managed licensing regularly, so treat any figure quoted outside its own pricing page as indicative only.
Usually, yes — but for a reason worth stating precisely. A small team creating one project with default settings does not experience much complexity at all. The complexity arrives with accumulated configuration, and a small team has neither accumulated any nor has anyone to maintain it later. If nobody outside your team dictates your process, you are paying for enforcement you will never use.
Any instance that will still be running in three years needs a named owner, even part-time. The role is less about configuring things than about declining to configure things: keeping the field taxonomy small, keeping workflow states meaningful, and retiring what a reorganisation left behind. Instances without that person do not fail dramatically, they just become slowly unusable.
Ask who owns the process. If your team designs its own workflow, Linear removes friction you are currently paying for. If the workflow is imposed from outside and compliance with it has to be demonstrable, Linear has deliberately not built the enforcement you need. Preference for one interface over another is a real consideration but it is the tiebreaker, not the decision.
You can, and it works well for intake and service-style queues where enforcement matters. It works badly for marketing calendars, campaign planning and client delivery, where the audience wants a visual surface and no vocabulary lessons. Forcing those teams in usually produces a shadow spreadsheet within a quarter, which is worse than having chosen a second tool on purpose.
The issue data moves easily. The process does not. Workflows, permission schemes, automation and any reporting built on custom fields have no equivalent in tools that deliberately lack those concepts, so the migration is really a process redesign. Add to that any marketplace apps that have become load-bearing, since each one is a separate vendor to unwind.
For a genuinely small group, yes — boards, agile reporting and custom workflows are all present. Treat it as an honest trial rather than a destination, since the constraints that push teams to pay are user count and storage rather than feature crippling, and both arrive without warning.
On their own, no. Assisted drafting, summarising and natural-language search now exist across every tool in this category at a comparable level, so they should not move a platform decision. If you are upgrading, upgrade for the planning, permission or governance capability in the tier and treat the AI as something that came in the box.
Because most people encounter it as a user of someone else's configuration. The experience that generates the complaints — twelve required fields, states nobody can define, a board that loads slowly because it queries half the instance — is the output of years of unowned accumulation rather than of the product's defaults. That distinction matters when you are choosing, because you are choosing whether to take on the maintenance, not just the software.
Full review coming soon.