An issue is a task, problem, or piece of work that needs to be done as part of a project
In project management tools like Jira, GitHub, Asana, or Monday.com, an issue is a single unit of work. It could be a bug that needs fixing, a feature someone requested, a design task, documentation that needs writing, or anything else the team has decided to track. Instead of keeping work in email threads or scattered notes, teams create issues so everyone can see what needs doing, who is doing it, and what state it is in.
The word "issue" comes from software development, where it originally meant a problem or defect. Over time, project management tools broadened the term to mean any trackable piece of work — not just problems. Some tools call them "tasks" or "tickets" instead, but they work the same way.
Key Takeaways
- An issue is a single piece of work — a bug, feature request, task, or problem — that a team tracks in a project management tool.
- Each issue has a title, description, status (like "open" or "done"), and usually an owner who is responsible for it.
- Issues can be linked to other issues, assigned a priority level, and organized into larger groups called epics or milestones.
- Using issues instead of email or chat keeps work visible to the whole team and creates a record of what was decided and why.
The parts of an issue and what they do
Most project management tools structure an issue the same way. At minimum, an issue has a title (a short name for the work), a description (details about what needs to happen), and a status (where it stands — often "open", "in progress", or "done"). The person or people responsible for the work are called the assignee or owner.
Beyond those basics, issues usually have a priority level (how urgent it is), a due date (when it should be finished), and sometimes a label or tag (like "bug", "design", or "urgent") that helps sort and find related work. Some tools let you attach files, add comments, or link one issue to another — for example, linking a bug report to the feature request that caused it.
The description is where the real detail lives. A good description explains what the problem is, why it matters, what the expected outcome should be, and any steps someone would need to take to understand or fix it. This matters because the person who opens an issue might not be the person who works on it, and they might not be available to answer questions later.
How issues connect to each other and to larger goals
A single issue is rarely alone. In most project management tools, you can link issues together — for example, marking one issue as "blocked by" another, meaning it cannot start until the other one is done. You can also group related issues under an epic (a large piece of work made up of many smaller issues) or a milestone (a deadline or release date that multiple issues are working toward).
This structure lets a team see the big picture. A product manager might create an epic called "User login redesign" that contains ten smaller issues: one for the password reset flow, one for two-factor authentication, one for the visual design, one for testing, and so on. Each issue can be assigned to a different person, but everyone can see how their work fits into the larger goal.
The difference between an issue and other ways of tracking work
Before project management tools became standard, teams tracked work in email, spreadsheets, or not at all. Email is private (only people on the thread see it), gets buried in inboxes, and creates no permanent record of decisions. A spreadsheet is visible to more people but is easy to forget to update and hard to link to actual work.
An issue in a project management tool is public to the team (or the whole company, depending on settings), stays in one place, and creates a searchable history. If someone asks "why did we decide to do it that way?", you can point to the issue and show the conversation that led to the decision. This matters especially in larger teams or when people leave and new people join.
How issues move through their lifecycle
Most issues follow a simple path. Someone creates an issue and gives it an initial status like "open" or "backlog" (waiting to be worked on). When someone starts working on it, they change the status to "in progress". When the work is done, they move it to "done" or "closed". Some teams add extra steps — "in review" (waiting for someone to check the work), "blocked" (waiting for something else), or "on hold" (paused for now).
As an issue moves through these stages, team members can comment on it, ask questions, or add new information. This creates a conversation thread attached to the work itself, rather than scattered across email or chat. When the issue is closed, that conversation stays with it as a record of what happened.
Why teams use issues instead of just talking
In a small team, you might be able to keep everything in your head or handle it in a quick conversation. But as a team grows, or as work becomes more complex, conversations get lost. Someone forgets what was decided. Two people start working on the same thing. A task falls through the cracks because no one wrote down who was supposed to do it.
Issues solve this by making work visible (everyone can see what exists), assigned (everyone knows who is responsible), and tracked (everyone can see the current state). They also create accountability — if an issue has been "in progress" for three weeks, that is visible to the whole team, and someone can ask what is blocking it.
Common mistakes when creating or using issues
The most common mistake is creating an issue that is too vague. "Fix the login page" does not tell someone what is actually broken or what success looks like. A better issue says: "Users report that the password reset email arrives in spam. Test with Gmail, Outlook, and Yahoo, and adjust the email headers to improve delivery." Now someone knows exactly what to do.
Another mistake is creating too many issues for one small task, or too few for a large one. If you create an issue for every single line of code, the list becomes noise. If you create one issue for "redesign the entire checkout flow", no one knows where to start or how to divide the work. The right size is usually something one person can finish in a few days to a week.
A third mistake is not updating the status. If an issue stays "in progress" for months, no one trusts the tool anymore. People stop looking at it and go back to email or chat. Keeping issues up to date takes discipline, but it is the only way the tool stays useful.
Frequently Asked Questions
Is an issue the same as a task?
In most project management tools, "issue" and "task" mean the same thing — a single piece of work that needs to be done. Some tools use "issue" for problems and "task" for everything else, but the structure and how you use them is identical. The tool you use will define which word it prefers.
Who creates issues?
Anyone on the team can usually create an issue, depending on the tool's settings. Often a product manager, project lead, or team member who spots the work will create it. The person who creates it does not have to be the person who does the work — they are just documenting what needs to happen.
What happens when an issue is closed?
Closing an issue marks it as done or resolved. The issue stays in the system as a record — you can still read it, search it, and see the conversation that happened around it. It just moves out of the active work list so people focus on open issues instead.
Can an issue be reopened if the work was not actually finished?
Yes. If someone closes an issue and later discovers the work was incomplete or the problem came back, they can reopen it. This moves it back to "open" status and puts it back on the team's radar. The full history of the issue — including when it was closed and why it was reopened — stays visible.
What if an issue is no longer needed?
You can close it with a note explaining why — for example, "This feature is no longer in scope" or "We decided to handle this a different way." Some tools let you mark issues as "wontfix" or "duplicate" to show why they are being closed. This keeps the record clear for anyone who looks at it later.