Short answer: In Jira, a story represents user-facing value (something a user can do now that they couldn't before); a task represents engineering work that doesn't directly produce user value (refactor, migration, config). Stories drive velocity; tasks don't. The rule that fixes most confusion: if you can describe the done state as 'a user can do X', it's a story. If you can only describe it in code or component terms, it's a task. Most teams over-use tasks and lose the unit of progress.
A Jira story symbolizes value for end-users. A task is engineering work that does not create value for users. The differentiation is the entire response to “task vs story Jira,” while most online articles oversimplify them.
“The simpler version is that stories face outward i.e. toward the end-user and stakeholders.” Focus on the team and your code. Both components exist within Jira’s hierarchy, both can have sub-tasks, both can roll up under an epic. It’s not how Jira shows them that is different, it’s what they each represent.
This guide explains the working definition, the rule that resolves most confusion, when each issue type is appropriate, the different treatment of them for velocity, and the most common over-use pattern that quietly breaks an agile team’s forecasting. Who the post is for: engineers, anchors, and PMs who've inherited a Jira instance and a backlog that's 70% tasks and want to know if that's a problem (usually, yes).
The working definition
User Story: It is a piece of user-facing value. It is expressed from the perspective of the user. For example, a user can recover their password. E.g., an admin can export the audit log. Also, e.g., a customer can pay with Apple Pay. The done state can be seen as user behaviour. The story is accepted by the PM when it’s possible for the user to do the thing.
Engineers and operations teams do tasks. These are pieces of work you do in engineering or operations that would not create direct user visible behaviour like upgrading your database to Postgres 17, or setting up the new CI runner. Atlassian's own Jira issue type guidance treats this hierarchy as configurable, which is partly why teams collapse the distinction. There is nothing to showcase as the work does not alter user functions.
Other types of issues in Jira on same level.
A bug is a defect it should have worked, but it didn’t. Bugs do not add new value, they are corrective work therefore they cannot be stories. Most teams prefer the specific Bug type instead of referring to it as a task.
A sub-task is a piece of a story or task that is small enough to track but not big enough to be an issue in its own right. If over-used, sub-tasks will become a kanban in a kanban, nobody maintains.
The all-encompassing hierarchy is known as epic. An Epic is a collection of related Stories and Tasks. Typically a feature, or other body of work, that is big enough to require multiple sprints. Themes do not require work items.
To know what makes a good story see principles of effective story writing.
The rule that fixes most confusion
There’s a single test we apply to all issues. Can you, by saying what a user could do now that they could not do before, describe what is done?**.
If the answer's yes, it’s story time. It's just a task, if you can only describe it in code or component terms. For example - "I refactored this auth module", "I upgraded Postgres" etc.
Illustrated Examples
- "Build the password-reset endpoint." → No user can do anything new; the endpoint is plumbing. Task.
- "A user who forgot their password can get back in." → A user can do something new. Story. (Same work, different framing.)
- "Migrate the staging environment to AWS Graviton." → No user change. Task.
- "An admin can see real-time order status on the dashboard." → User change. Story.
- "Add unit tests for the cart service." → No user change. Task.
- "Cart abandonment emails go out within 30 minutes of inactivity." → User-facing behaviour. Story.
Many teams excessively use the Task type as engineers instinctively label their work in engineering terms. The solution is to implement the aforementioned test during backlog grooming activity. Reframe any “task” to a story if it does not lose its meaning. The team will devote lesser time on arguing over issue type and more time on completing user value.
Why the distinction matters — velocity
Velocity is the reason why this has greater significance than a labelling argument.
Velocity helps teams predict how much value was delivered to end-users. It is an average of the last three iterations. In a healthy agile setup, velocity is the only story. Tasks do not. The rationale behind this is velocity aims to estimate the user value the team can deliver. If a team includes refactors, infrastructure work, and bug fixes into velocity its number keeps increasing regardless of whether the users received anything.
There’s a rock-solid failure mode: teams that count tasks in their velocity see this number stay the same or grow while engineering work increases even when no features are being shipped. The project manager trusts the development velocity, makes plans based on it, and is then surprised when nothing is ready for demo at the end of the quarter that can be shown to users.
The solution involves configuration in order to limit point attachment only to stories. Tasks are monitored but not estimated. Bugs are monitored but not assigned a point value (they originated from a pointed story; you don't get to point it twice). Although chores are tracked, they are not pointed. Chores refer to the Pivotal term for support work — see why bugs and chores stay unestimated for the reasoning behind that split.
This has a viewpoint. If you set up Jira accordingly, any issue type can be tracked. So will most generic agile tooling. Tools designed by engineers, such as the original Pivotal Tracker, impose a ruling on stories by default. Labelling discipline will drift and structural enforcement will not, hence the focus on structural enforcement — Martin Fowler's note on user stories makes a similar point about keeping the user-perspective frame fixed in the artifact itself.
When the issue type really is "task"
The Task type is suitable for work that requires monitoring but doesn't deliver any user benefit.
- Infrastructure and platform work. Database upgrades, CI configuration, secrets rotation, dependency updates.
- Refactoring without user-visible change. Moving code around, splitting modules, untangling dependencies. If the user can't see it, it's a task.
- One-off operational work. Setting up the new staging environment, configuring an integration, running a data migration.
- Documentation that isn't user-facing. Engineering docs, runbooks, post-mortems. (User-facing documentation — onboarding, help articles — is sometimes a story if it changes what a user can do or understand.)
It’s not bad to use the Task type. The error lies in employing it for tasks that are, in reality, a narrative in engineering terminology. Essentially, do not say, “I made PDF exporting.” Instead, say “you can now export your data as a PDF” or just “you can export PDF files.”
The most common over-use pattern
After working with dozens of teams on their JIRA backlogs, one pattern I see happening again and again. The team tells me they have 200 issues. 180 of them are tasks while 20 are stories. The "stories" are large, fuzzy themes. The “tasks” represent elaborated engineering work.
You are playing it wrong. In a good backlog, the ratio flips – there are mostly stories (small, user-facing, independently shippable) and only the truly non-user-facing stuff are tasks.
Typically, one of three factors causes the inverse ratio.
- The team imports tickets from engineering Jira directly into the agile backlog. Engineering Jira has historically used Task as the default; the agile practice was bolted on later.
- Stories aren't broken down into shippable units. When a "story" is two months of work, the only way to make progress visible is to add a swarm of tasks beneath it. The fix is smaller stories, not more tasks — see choosing the best slice for your story for a working method.
- The PM isn't actively writing stories from the user's perspective. Engineering self-generates work in engineering terms by default. Without a PM holding the user-perspective line, the backlog drifts toward tasks.
The solution to all three problems is to check - “Does it help a user do something new now?” during backlog grooming. If you answer yes, rewrite it in story form. Retain as a task if answer is no. In the next quarter, the ratio is reversed, and the velocity of the team is a useful number for the first time.
Frequently asked
What's the difference between a task and a story in Jira?
A story depicts user-facing value which is anything a user can do that she could not do before. A task is engineering or operational work that does not create user-visible change. It is stories that drive velocity, not tasks. In Jira's hierarchy, both reside at the same level.
When should I use a story vs a task in Jira?
If there’s user behaviour allowing observation of the done state (e.g. a user can recover their password), use a story. If the task is internal to engineering and does not result in a user-visible change, use a task. A task might be "upgrade the database to Postgres 17". Can you explain whether something is done by describing what a user can now do that he could not do before?
Do tasks count toward velocity in Jira?
Jira assumes all pointed issues are counted towards velocity. In a healthy agile set-up, only user stories count. Bugs, chores, and tasks should be tracked but not pointed. This preserves velocity as a forecast for user value that gets shipped, not engineering activity.
Can a task become a story in Jira?
Yes, most of the time it should. A lot of “tasks” are stories that are written in engineering language. Instead of saying “build the password-reset endpoint,” which sounds a lot like asking a developer to “build the tractor,” reframe it as the story: “a user who forgot their password can get back in.” Similar work, more useful framing.
What's a Jira epic?
This refers to the container for associated stories and tasks that usually is large enough to span a number of sprints. Epics refer to a theme (a feature, an initiative), rather than a work item. The stories underneath an epic are where the real work occurs, not the epic itself.
What about sub-tasks?
It refers towards something small enough to keep an eye on but too large to be an issue. They are useful in moderation, if over-utilised sub-tasks become like a board inside a board which no one maintains. Most teams find the value of splitting a too-big story into multiple smaller stories preferable to adding sub-tasks.
How do you handle bugs in Jira?
Utilize the specific Bug type, not Task. Bugs are points from the original story that caused them, so there’s no repointing of the bug story. Bugs aren’t counted towards your team’s capacity/velocity but you should track them, prioritise, and ideally fix them in the next iteration.
Why does the story/task distinction matter so much?
Due to its impact on velocity. When a team includes engineering tasks in velocity, the number goes up, even if users didn’t get anything new. The PM schedules work according to that number and is surprised by the quarter delivering no features. The practice of keeping points only on stories makes velocity a real forecasting tool.
Still stuck
When your team writes stories from the user’s perspective and that only stories carry points tasks are tracked, not estimated you’ve got the discipline right. The labelling in Jira is a practice that occurs later in the process.
LiteTracker is for you if you want a tool that forces you into stories-only velocity by default, won’t let you point at tasks or bugs, and surfaces a single ordered backlog (not a configurable maze).
The initial tier is free and comes with unlimited customers and an import that takes approximately a minute. Save the migration. If you’re entrenched in the defaults and your team has managed to make them work, skip us.
In any case, engineering should not frame the stories. Frame engineering through stories.