Why Does Linear Call Them "Issues" Instead of "Tasks"? Three Design Decisions Behind the Word
TL;DR
Linear’s choice of “issue” over “task” or “story” is not an accident. Three design decisions sit behind it: a connection to software development culture (most visibly GitHub Issues), a wider semantic range than “task,” and a deliberate distance from agile vocabulary. On top of that, Linear flatly calls user stories “cargo-cult” and proposes a separation of concerns: Why goes in the Project Document, What goes in the Issue.
The Choice of the Word “Issue”
When people start using Linear, a simple question often comes up: why “issue” and not “task”? Jira uses “ticket” or “story,” Asana uses “task.” Three intentions can be read into Linear’s choice.
1. Connection to Software Development Culture
Since GitHub Issues, “issue” has been one of the most familiar terms in the software developer vocabulary. Linear is designed as a tool for engineers, and naming it “issue” plugs straight into the language its target users already speak.
2. Broader Meaning Than “Task”
“Task” narrowly means “work to be done,” whereas “issue” can encompass bug reports, feature requests, improvement proposals, investigations — any kind of thing that needs to be resolved. Linear’s official docs even define an issue as “a task described in plain language,” positioning a task as one form of issue rather than the other way around.
3. Deliberately Avoiding Agile Vocabulary
This is the most interesting point: Linear holds the philosophy of deliberately not using traditional agile terms (user stories, epics, etc.). One review article points out that Linear doesn’t even use the word “agile” anywhere in its documentation.
”User Stories Are Cargo-Cult”
The most provocative piece of Linear’s philosophy is its official page titled Write issues, not user stories, where Linear explicitly frames user stories as an anti-pattern. Their argument breaks down like this.
They’ve become outdated. User stories were born more than 20 years ago as a way to translate customer wants into requirements an engineering team could understand. But today, customers are themselves tech-savvy, and standard patterns are already established for common features like shopping carts and notifications. Linear’s view is that there’s no longer a need to write “As a user, I want to…”
They’ve become a cargo-cult ritual. “Cargo-cult” comes from a story about post-WWII Melanesia, where locals built wooden mock-ups of runways and control towers in an attempt to make the planes that brought supplies return. The metaphor refers to imitating only the form without obtaining the underlying effect. Linear argues that user stories have become exactly this — writing in the format “As a user, I want to…” has become an end in itself, drifting away from the original goal of “understanding the user.”
They shrink engineers’ thinking. Describing tasks indirectly makes the actual work to be done ambiguous and confines engineers to the mechanical role of “writing code to spec.” The criticism is that this robs them of the chance to think holistically about UX at the product level.
Linear’s Answer: Separation of Concerns
So where does the “why are we building this” context-sharing role of user stories go? Linear’s answer is simple: make the place you write the Why and the place you write the What clearly different.
| Layer | Where it lives | Contents |
|---|---|---|
| Why (why are we building this) | Project Document | Spec, PRD, user research, background |
| What (what to do) | Issue | Concrete work tasks |
Project Documents support Markdown, collaborative editing, and inline comments, and Linear officially describes a workflow where “the project lead writes the spec, others contribute to the brief, then the work is divided up and each person writes their own issues.”
flowchart LR
A[Project Document<br/>Why: background, spec, PRD] --> B[Issue A<br/>What: concrete work]
A --> C[Issue B<br/>What: concrete work]
A --> D[Issue C<br/>What: concrete work]The user-story style embeds context into every individual task again and again. Linear’s approach consolidates the Why in one place and stops repeating it inside each issue. The premise is that everyone on the team enters the work having already deeply understood the user needs and requirements, so the task level doesn’t need to spell them out every time.
Critiques and Their Limits
There are critiques of this philosophy. One Medium article takes Linear’s own “pinned tabs” feature as an example, arguing that removing user stories causes the Why to be lost and lets development proceed with unclear goals.
That critique has some weak spots, though.
It doesn’t mention Project Documents at all. The author appears to be a Linear user, but they don’t engage with Linear’s official workflow of “write the spec / PRD in a Project Document, define the purpose of the feature there, then break it down into issues.”
They critique only the issues. They take “there were only tasks” as the problem, but in Linear Method the background is supposed to live in the Project Document above those tasks. If even the Project Document was missing the background, that’s not a Linear Method problem — it’s an operational problem with that team.
The same thing can happen with user stories. Even if you wrote “As a user, I want to pin tabs so that I can quickly access them,” if the discussion of concrete behavior is missing you’ll end up in the same place.
Compatibility with Jobs To Be Done
Interestingly, the same Medium article ends with “user stories are even older — Jobs To Be Done (JTBD) is the modern approach.” JTBD is the idea that “people don’t buy products, they ‘hire’ a product to get a ‘job’ done,” made famous by Christensen’s milkshake example.
Ironically, JTBD is a framework used at the product strategy level, not the task level. Which means it’s actually quite compatible with Linear Method’s stance of “discuss Why in the Project Document, keep issues simple.” Use JTBD to deeply understand the customer’s “job,” distill that into a Project Document, and break it down into issues from there — that flow is precisely Linear’s design philosophy.
Conclusion
Linear’s choice of “issue” isn’t just a vocabulary preference. It packs three intentions: a connection to software development culture, a wider semantic range, and distance from agile formalism. And behind the provocative claim that “user stories are cargo-cult” sits a practical design principle: separate the place you write the Why from the place you write the What.
Personally, I don’t think you need to reject user stories outright, but I find the lens of asking whether the form has become the goal useful. Are you writing “As a user, I want to…” on autopilot? Is it actually an exercise in understanding the user? Linear’s separation of concerns — Project Document plus Issue — is one clear answer to that question.
That’s all.