Task vs issue in agile methodology: tasks are work, issues are obstacles
A task is planned work that produces something. An issue is an unplanned obstacle. Most project management tools collapse them into the same object, and that's the cause of every messy backlog.
Open any project management tool and look at the backlog. Two hundred items, sorted by priority, color-coded by some convention nobody remembers agreeing to. Some of those items are real work the team needs to ship. Some are surprise fires individual team members, or the entire team is fighting today. Most tools can't tell you which is which.
That's a problem. And it's a problem most teams have learned to live with by writing it off as "messy backlogs," when the real cause is more specific. The tool collapses two fundamentally different objects into the same bucket.
What a task actually is
A task is a unit of planned work that produces something. Build authentication. Design the onboarding flow. Migrate the user table from Postgres 14 to 16. Write the API documentation for the public endpoints.
Tasks have three properties worth naming.
They have a clear "done" state. You can look at the result and confirm the task is finished.
They are part of the project's intended structure. Someone planned them, deliberately, as part of getting from start to ship.
And they unlock other tasks. Finishing one task moves the project forward, often by enabling something else to start.
Tasks are the structure of the project. Without them, there's no project.
What an issue actually is
An issue is an unplanned obstacle to executing planned work. The Postgres database is throwing intermittent timeouts. The Stripe API returns 500 errors on weekends and nobody knows why. The designer is on vacation and the marketing review is stuck waiting.
Issues have different properties.
They get resolved, not completed. The goal is to make them go away, not to tick them off a list.
They're not part of the project's structure. They appeared because something broke or someone got blocked.
They block other work. The whole point of an issue is that it's preventing planned work from happening.
Issues are obstacles to the structure. Without them, the project still exists. With them, the project just temporarily can't move.
Why most tools collapse them anyway
Most project management tools collapse tasks and issues because one flexible object is easier to build than two strict ones. The trade-off was made by Jira early in its life and copied by almost everything that came after.
Atlassian's strategic decision was simple. Every work object would be an "issue." Tasks, bugs, stories, epics, sub-tasks: all variants of the same underlying thing, distinguished by a type field. The reason was technical and reasonable. One flexible object is easier to build, store, and query than two strict ones.
The decision still echoes in Atlassian's own help pages today. The documentation quietly notes that a single work item can only display up to 500 child work items, and recommends keeping projects under that limit. Read that sentence twice. The tool has a hard ceiling on how much work you can model under a single parent. The ceiling exists because the underlying object is so flexible that someone, somewhere, was modeling 600 child items as siblings of a single parent. The data model permits absurdity. Users build absurdity.
Most tools that came after Jira followed the pattern. Linear has issues. Notion has database rows. Asana has tasks that can also be bugs that can also be initiatives. The label varies. The underlying object doesn't.
The cost of that decision is paid by users. When everything is the same kind of thing, you can't see at a glance what's planned work versus what's a fire. The tool is technically correct and practically useless for the question every team asks first thing on Monday morning. What's the real state of this project?
The two failure modes this creates
Collapsing tasks and issues creates two predictable problems: backlogs that misrepresent reality, and status updates that describe symptoms instead of causes.
Backlogs that lie
A 200-item backlog mixing planned work with current blockers makes the roadmap look twice as full as it is. The team thinks they have a hundred tasks ahead of them when really they have sixty tasks and forty fires. Capacity planning becomes guesswork. Sprint planning becomes negotiation about which fires to put inside which sprint, when fires don't belong in sprints at all.
The team's velocity numbers lie too. A sprint that "completed 18 issues" tells you nothing about whether the project moved forward. Maybe it moved forward 18 steps. Maybe it put out 14 fires and shipped 4 small features. The metric pretends those are the same.
Status updates that don't help
When somebody asks "what's blocked," the standup reports back a list of ticket IDs. Half of those tickets are blockers. Half are tasks that depend on the blockers. The team describes the symptom rather than the cause.
Three weeks later, the same blocker is still there, now hidden under a chain of dependent tickets nobody's tracing back to the source. The team has been working on the dependent tickets in rotation, finding new things to do around the blocker rather than fixing it. The blocker has become invisible because the tool stopped distinguishing it from the work it was holding up.
How Tree separates them
Tree models tasks and issues as two different kinds of objects with different lifecycles. Tasks live in the tree's structure. Issues attach as flags to the tree's nodes.
A task in Tree is a node. Tasks have prerequisites. They unlock other tasks when finished. They have a permanent "done" state. Once a task is complete, it stays in the tree forever as part of the project's history. The tree itself is the record of what was planned and what got shipped.
An issue in Tree is a flag attached to a node. Flags don't appear in the tree's structure. They appear as red marks on whichever nodes they're currently blocking. When a flag is resolved, it's removed from the node. The node returns to whatever state it was in. The flag doesn't stay on the project's history because it was never part of the project. It was a thing that happened to the project.
When somebody asks "what's blocked" inside Tree, the answer is a list of red flags, with the obstacles named. Not ticket IDs. Reasons. The team can address the cause instead of the symptom. When somebody asks "how is the project going," the answer is a tree with completed nodes, in-progress nodes, and locked nodes. Issues don't pollute the picture.
This isn't a Tree-only opinion
Plenty of teams using existing tools already enforce the distinction by convention, even when their tool doesn't. The pattern is real. Tree just commits to it at the data-model level instead of leaving it to discipline.
Some Jira teams keep bugs out of sprint planning views. Some Linear teams use a separate project for incidents. Some Asana teams have a "fires" workspace and a "roadmap" workspace, and never the twain shall meet. The conventions work. They work as long as everyone follows them.
The point isn't that Tree invented the idea. The point is that conventions decay. New hires forget. Tired teams cut corners. The tool's defaults eventually win. Tree commits to the distinction at the data-model level so the tool's defaults are the right ones.
The takeaway
Whatever tool you use, the distinction matters. If your tool collapses tasks and issues, you'll fight the tool forever. You'll write conventions in your team handbook. You'll train new hires on which type field to pick. You'll watch those conventions slip every quarter.
If your tool separates them, you can tell at a glance what's planned versus what's burning. Tree does the latter. On purpose.