What should you actually look for in issue tracking systems?

Short answer: An issue tracking system is software that records bugs, incidents, and work items so a team can find them again, decide what to do about each one, and prove what changed. The five fields that matter on every issue: title, reporter, assignee, severity, state. Most teams over-configure their tracker and then can't search it. The fix is fewer fields, boring workflows, and treating the tracker as a read tool first.

The software application used for logging bugs, incidents, and work items, in a way that the team can find again later. Thus, this is the complete product.  Everything else, including fields, workflows, dashboards, automations, integrations, either facilitates or impedes goal accomplishment. Most teams use tools that impede goal accomplishment.

It is important to note that the issue tracker is something that gets read often, and less often written. Bug is put in once. This issue gets searched 5 times during triage, opened twice in a sprint planning meeting, linked from a Slack thread, referenced in a post-mortem, and dug up by a new hire trying to understand why a part of the codebase looks the way it does. The same row read pattern shows up in tracker search behaviour — a tracker which is unrecognizable by a stranger after six months is failing its actual job.

This guide explains what an issue tracking system records, five fields which earn their keep, what is the difference between an issue tracker and a project management tool, which shape of workflow survives contact with reality and configuration mistakes making a useful tracker a write-only graveyard. Engineering leads and PMs choosing or rationalising tooling.

What an issue tracking system actually is, plainly

An issue tracker is a thin UI on top of a database. The rows represent issues, while the fields are the columns that you choose to record about each issue. Examples of issues are a bug, piece of work, incident, etc. The graphical interface offers means to filter, search and update entries. When rows change that you care about, notifications let you know. That's the full blueprint.

What issue tracker is not.

• A roadmap tool. Roadmaps are about themes and time, not individual rows. Trackers don't summarise well.
• A documentation system. Issues are short and contextual; they're not where you write down how the system works.
• A communication channel. Comments on an issue are a record of decisions, not a chat replacement.
• A KPI dashboard. Bug counts and "time to close" make for impressive slides and bad management decisions.

We heavily overlap with project management software (which adds planning, capacity and sprint structure on top of issues), incident management software (which adds paging, runbooks, and post-mortem flow) and help-desk software (which adds customer-facing queues and SLAs). A team can use one combined tool for everything or four distinct tools that can communicate with each other. The right choice depends on the size of your team, so choose by the team size, not the vendor pitch.

Issue tracker vs project management tool — the overlap

The truth is, most issue trackers in use today also deliver project management functionality. And vice versa. The product design focused on certain jobs; the difference is which job it was 聚焦 on first.

When selecting a feature, it should not be based on the one that has more capabilities rather which job is the team going to do daily. A bug-heavy support team should choose something issue-first. The product development team should prioritize first story or as a cycle. As long as you’re a small engineering org running one product, you can get away with one tool covering both jobs; the moment you have specialist support engineers separate from feature engineers, the two jobs deserve two tools. Teams moving between trackers usually hit the same wall — migrating from a heavy Jira instance is mostly a re-shaping exercise, not a re-import.

The five fields every issue needs

Through much experience in working with Jira instances, a repetitive pattern emerges: trackers that remain legible consistently have about five fields per issue. Thirty trackers that no one can search for.

These five deserve their recognition.

1. Title. A short imperative or declarative sentence. "Password reset email doesn't arrive when the address has a plus sign." Not "PASSWORD ISSUE." Not "Investigation: email." Titles are the only field most readers ever see in a list view; they have to carry the meaning alone.
2. Reporter. Who filed the issue. Matters because the reporter is who you go back to for context, and who confirms when it's actually fixed.
3. Assignee. Exactly one person, never a team alias, never empty for more than a day. The single owner test: if no one knows the assignee, nobody is working on it, regardless of what the comments say.
4. Severity. How bad it is for users. Not how big the engineering work is — that is "priority" and means something different (see below). Three or four levels is enough; ten is theatre.
5. State. Where in the workflow it currently sits. Boring states beat clever ones (see workflow section).

The optional functionalities include labels, components, fix versions, custom dropdowns, sprint pointers, parent links, custom multi-select fields. Include them only when they show potential of being searched against more than once a month. They embellish the tracker without disclosing it.

To file issues, we require teams to fill out one additional field. Each additional required field is a tax on filing an issue. Simple math. Every tax raises the threshold for filing. This means that the only things that get filed are those that are important enough to overcome the tax. This means that useful smaller signals never get into the system. More issues but less noise.

Workflow states: keep them boring

Every new tracker admin’s first work is to design a custom workflow with eight states, sub-states, conditional transitions, and approval gates. After a period of six months, nobody remembers what “Triaged: pending owner ACK” means and every issue sits in it.

The tedious workflow that stands the test of reality.

• New — just filed, not looked at yet.
• In Progress — someone is actively working on it.
• In Review — the work is done but waiting on PR review, QA, or stakeholder sign-off.
• Done — closed because shipped, won't-fix, duplicate, or invalid.

Four circumstances. Your team can use a Blocked state when they have external dependencies that genuinely stop work for days. Otherwise, blocking should just be a comment. You should only add custom states to your workflow when it is based on a real stage in the real world which is not captured. And even then, think about whether the team will act to move their issues into or out of this state. Otherwise, it runs the risk of becoming a dustbin-like “hiding place” effect where issues go to die.

The Done reason is already its own filed, whenever closed, won't-fix, duplicate, invalid, deferred, etc. This is important when searching for historic issues – “all closed issues” is not the same as “all fixed issues”.

Severity and priority are not the same thing

The field collision that causes the most fights is this. Severity refers to the level of impact on users. Priority refers to the next task which should be performed. Although they are related, they are not the exact same column.

It may be okay to prioritize a big bug affecting three users on a deprecated browser over a moderate bug affecting every login. A minor bug in a feature set to launch tomorrow may rise to high priority for just one day before returning to low priority post-launch. Priority changes; severity typically remains unchanged.

The more elegant approach is to note severity on the issue itself (because that is a property of the bug) and to regard priority as an ordering of the backlog (which team re-visits at backlog refinement). Severity is a characteristic; priority emerges from the arrangement of observations. Most trackers just have a single "Priority" dropdown that collapses them all and calls it a day. Most teams then spend the rest of the tool's lifetime arguing whether their P1 means “users are screaming” or “we should fix this next”.

LiteTracker is designed to have such a pattern   a single ordered backlog where priority is the order and severity is a per-issue property. The choice made removes any further discussion. In less strict environments, it applies anywhere: separate the property from the queue position or be prepared for a never-ending debate about priority.

The reporter-assignee separation

Another important field that often goes unnoticed is that of reporter and assignee.  Although they appear to be similar data types, as they’re both “person”, they serve wholly different purposes. Conflating the two is the slow route to a tracker nobody trusts.

The reporter is the one who filed it. They’ve seen the bug already, they have the steps to reproduce it, and they are who you go back to when the engineer fixing it needs context. It is the reporter that also confirms the fix; the engineer can mark “done” but it is only the reporter that knows the symptom has gone away.

The individual currently engaged in the task is the assignee. It is common to reassign issues when the work keeps changing hands. The reporter is not to be altered in any way, other than trivial cleanup like merging duplicate filings.

The importance of this feature: if your tracker is healthy, you can search for “issues reported by Person X in the last quarter” and get back a real list of things Person X reported. You can search “issues currently assigned to Person Y” and get a real list of what they’re on. In case the reporter and assignee are merged or the reporter gets overwritten upon reassignment, the queries will not function successfully thereby rendering the tracker opaque to the onlookers trying to comprehend the situation.

Search is the main feature, not a side feature

Whether the team can find an old issue is the biggest single predictor of whether a tracker stays useful at one year, three years, five years.

Search needs to handle.

• Free-text across titles, descriptions, and comments.
• Field filters: state, severity, assignee, reporter, component, date ranges.
• Saved searches / shared filters — the same query, named and reusable, because every team has the same five queries they run every week.
• Stable URLs — every search result and every issue has a permanent URL you can paste into Slack, a PR description, a post-mortem.

When a tracker fails any of these, working around it becomes a discipline of its own. Instead of searching for workarounds, the team simply asks. A tracker can become a write-only graveyard when the team stops looking.

Cycle times decrease from days to hours and teams reach users 14× faster   but only when the next thing in the backlog is findable. Search-less issue trackers lose the speed advantage of an ordered backlog just like Kanban.

Notifications: silence first, then noise

All trackers have the same notification system failure mode. You begin with an empty inbox. A user enables "notify me on all mentions". After that, all the tweaks to issues I devised.  "Then any modifications that are made to issues within my project." After six weeks, 400 untracked emails that I’ve filtered and bypassed into some folder I never bother to open.

Most effective pattern!

• Notify on assignment — you get told when something becomes your problem.
• Notify on @mentions — someone explicitly asked you a question.
• Notify on state changes for issues you reported — you find out when your bug gets fixed.

All other things: not by default. Watch lists on a per-issue basis for occasions where a specific row matters. The remaining receive daily or weekly updates.

“Most trackers have a default of notify on too many things as the vendor product managers optimise on engagement metrics.” When installing any tracking software, the first thing to do is turn the defaults off. Then turn back on only the 3 signals above. The tracker is important to the team only if the notifications mean something. The same restraint shows up in Martin Fowler’s writing on technical debt and triage discipline — fewer signals, more action.

When NOT to add an issue tracker

There are cases where adding a tracker makes things worse - this is a candid counterpoint to the idea that every team should have one.

• Solo developer, no users yet. A README and a TODO.md are sufficient. Adding a tracker is process for the sake of process; the overhead is real and the benefit is zero.
• Team of two, daily standup. Verbal coordination plus a shared spreadsheet works fine for very small teams. The moment you grow to four or five, the tracker earns its place — but until then, the spreadsheet is honest about how much structure you actually need.
• One-off project that's already in flight. Don't bolt on a tracker mid-project unless something is genuinely broken. The cost of migrating in-progress work outweighs the benefit, and you spend the rest of the project arguing about whether issues belong in the old or new system.
• The team is using the tracker for a job it isn't designed for. If you're storing customer feedback, feature requests, sales notes, or roadmap themes in your bug tracker, you're going to hate it. Use a different tool for those, and let the tracker stay focused on issues.

To summarize everything for the others: Yes, a tracker is indeed a good idea. Choose the one that doesn’t hinder your progress. LiteTracker functionalities take care of the 20% that provides 80% of the results. The other 80% is what slows enterprise tools down to a crawl. If you don't have three engineers and aren't running iterations yet, skip the sign-up. Free tier, unlimited users and come back when you have grown into the need.

Frequently asked

What is an issue tracking system?

Software that documents bugs, incidents, and work items so that a team can find them again later, decide what to do about each one, and prove what changed. The functions of service management are similar to a project management tool, an incident management tool, or a help-desk system. But the core job is ‘remember everything, in a way you can search’.

What's the difference between an issue tracker and a project management tool?

The initial job they were designed for. Issue trackers are designed to facilitate row-wise search and field discipline. Project management tools focus on views of what the team is doing right now. Although many elements are widely used across various applications, most don’t feel overloaded until examined in context.

What fields should every issue have?

A minimum of five includes title, reporter, assignee severity and state Only add more items after verifying that they are consistently searched upon more than once a month. Every additional required field increases the cost of filing. This reduces the number of issues filed, which weakens the signal.

How many workflow states do I need?

For tracking work, four states are usually sufficient: New, In Progress, In Review, Done. Optionally include Blocked where external dependencies genuinely halt work. Many teams opt for custom workflows with 8 states and conditional transitions. However, this mostly results in an issue hiding place.

Is severity the same as priority?

No The level of severity refers to a property of the issue wherein the severity explains how bad the issue is for the users. The backlog ordering of priority defines what we should work on next. They are related, but they are different columns. Combining them gives rise to the argument on whether P1 is 'the users are screaming’ or ‘we fix it next’ that never resolves.

What's the best issue tracking system?

Your team should keep it neat and tidy. Jira continues to be the most commonly used issue tracker. Linear and GitHub Issues are among the more common tools in modern development teams. Pivotal Tracker was the favourite in the engineering shape until its 2025 shutdown; its more recent successors (including LiteTracker) are targeting the same shape. The optimal situation is something that is consistently used and good enough.

Can a small team get away without one?

Indeed, but only to a point. Regular verbal coordination and a shared TODO list can usually suffice for a solo developer or a team of two. A tracker begins proving its worth by four or five people. When it becomes a question you regularly ask, then don't forget.

Why do most teams' trackers turn into graveyards?

Three reasons (not two): Excessive required fields (increased filing costs); excessive workflow states (hiding issues); excessive notifications (team filters bypass the tracker, and they stop reading it). If you fix all three, the tracker stays alive.

Still stuck

A tracker with five fields per issue, four states, search, and notifications that don’t scream is worth most of the value. Most of the time, disagreements around which issue tracker to use, rather than what issue trackers do and whether they help. However, the tool the team uses is less important than the discipline they develop.

LiteTracker was specifically designed for clients looking for fewer engineered fields, a single ordered backlog, and accepted-stories-only velocity. You can import unlimited users in under a minute within the free tier. If you’re a satisfied Jira admin and the team has successfully adapted to its default settings, feel free to avoid the migration and skip us.

Regardless of which, keep the tracker small, keep search working, and treat it as a “read” tool first.