An issue is a problem, blocker, or risk that stops work or slows it down
In project management tools, an issue is anything that gets in the way of finishing a task or moving a project forward. It might be a bug in code that breaks a feature, a missing piece of information you need to decide something, a person who is unavailable when you need them, or a vendor who missed a important date. Issues are different from regular tasks because they represent something that has gone wrong or could go wrong — not just work that needs doing.
Most project management tools let you create an issue, describe what the problem is, assign it to someone, and track it until it is solved. The issue stays visible to the whole team so nobody forgets about it or assumes someone else fixed it. When the problem is resolved, you close the issue and move on.
Key Takeaways
- An issue is a blocker, problem, or risk that prevents work from moving forward, not a routine task.
- Issues are tracked separately from regular tasks so the team can see what is actually stopping progress.
- Each issue should have a clear description of the problem, who is responsible for fixing it, and what "fixed" looks like.
- Issues can be linked to the tasks or projects they affect, so you can see the full picture of what is broken and what depends on it.
How issues differ from tasks
A task is work you plan to do. An issue is something unexpected that got in the way of that work. If your task is "Design the checkout page," that is a task. If you discover the payment processor does not support the currency you need, that is an issue — it blocks the checkout page from being finished.
In practice, this means issues usually need faster attention than regular tasks. A task can wait a few days. An issue that is blocking three other people needs to be solved today. By separating them in your tool, the team can see at a glance what is actually urgent versus what is just on the to-do list.
What information goes into an issue
A useful issue includes a clear title that says what is wrong, not just "Problem" or "Help needed." Instead of "Bug," write "Login page times out after 30 seconds on mobile." Instead of "Blocker," write "Client has not provided brand guidelines, cannot start design."
The description should explain what happened, what you expected to happen, and why it matters. If it is a technical bug, include steps to reproduce it. If it is a missing decision or approval, say who needs to provide it and by when. Assign the issue to the person who can actually fix it, not to a manager. Add a priority level — critical, high, medium, or low — so the team knows what to tackle first.
Many tools let you link an issue to the task or project it affects. This creates a chain of visibility: someone looking at a task can see "This is blocked by Issue #47" and click through to understand why work stopped.
Types of issues teams commonly track
A technical bug is code that does not work the way it should. The user sees an error message, a feature crashes, or data disappears. These are usually assigned to a developer and marked high priority because they affect the product users see.
A blocker is something outside your control that stops you from moving forward. A vendor did not deliver a file. A decision maker has not approved the direction. A person you need is sick. Blockers are often assigned to a manager or the person who can unblock it, and they get flagged so the team knows why progress has stalled.
A risk is something that might go wrong if you do not act. A important date is coming up and you are behind schedule. A team member is about to leave. A new regulation might affect your product. Risks are tracked so the team can plan around them before they become actual problems.
How to write an issue someone will actually fix
The clearer you are about the problem, the faster it gets solved. Vague issues sit open for weeks because nobody knows where to start. Specific issues get fixed because the person assigned knows exactly what they are looking for.
Instead of "The app is slow," write "The dashboard takes 8 seconds to load on a 4G connection; it should load in under 2 seconds." Instead of "Design feedback," write "Client wants the hero image moved below the headline and the button color changed to match the new brand blue (hex #0047AB)." Instead of "Need approval," write "Waiting for Sarah to approve the budget increase for freelance copywriting by Friday so we can hire by next week."
Always include what done looks like. For a bug, that might be "User can log in on mobile without timeout." For a blocker, it might be "Sarah has approved the budget in writing." For a risk, it might be "We have a backup plan documented and the team has reviewed it." When the person assigned knows what success looks like, they can close the issue with confidence.
When to create an issue versus just talking about it
If it is a one-sentence problem that gets fixed in five minutes, you might not need an issue. If the developer sitting next to you says "The button is the wrong color," and you fix it when ready, that does not need to live in your tool.
Create an issue when the problem affects more than one person, will take more than an hour to fix, needs someone who is not in the room right now, or might come back up later. Create an issue when you need a record of what went wrong and how you fixed it. Create an issue when the problem is blocking someone else's work.
The rule of thumb: if you would forget about it by tomorrow, or if someone else needs to know about it, it belongs in your tool.
How issues connect to the bigger picture
A single issue might affect multiple tasks or projects. If your payment processor goes down, that blocks checkout, account upgrades, and refunds all at once. By linking the issue to all three, the team can see that one root cause is stopping three different pieces of work. When the processor comes back online, closing that one issue automatically shows that all three tasks can resume.
Some teams use issues to track decisions that need to be made. "Should we use React or Vue?" becomes an issue assigned to the tech lead, with a important date and a description of what information is needed to decide. Once the decision is made, the issue closes and the team moves forward with one answer instead of debating it in three different Slack channels.
Frequently Asked Questions
What is the difference between an issue and a bug?
A bug is a specific type of issue — something in the code that does not work right. An issue is the broader category: bugs, blockers, risks, missing information, anything that stops progress. All bugs are issues, but not all issues are bugs.
Should I create an issue for every small problem?
No. If it takes five minutes to fix and only affects one person, you probably do not need it in the tool. Create issues for problems that block other people, take real time to solve, or need to be tracked so the team remembers them later.
Who should be assigned to an issue?
Assign it to the person who can actually fix it or unblock it, not to a manager or the person who reported it. If a vendor needs to deliver something, assign it to the person managing that vendor relationship. If code is broken, assign it to a developer. If a decision is needed, assign it to the decision maker.
What should I do if an issue is assigned to me but I cannot fix it?
Update the issue to say why you cannot fix it and reassign it to the right person, or add a comment explaining what information or help you need. Do not leave it sitting assigned to you while someone else actually works on it — that confuses the team about who is responsible.
Can an issue stay open forever?
It can, but it should not. If an issue is not being worked on, either close it with an explanation of why it will not be fixed, or update it to say when work will start. An open issue should always mean "someone is working on this or about to work on this," not "we are thinking about this someday."