# How to run a bug tracking board that stays tidy

> Run a bug tracking board that does not turn into a graveyard: what a bug card needs, how to triage, how to rank bugs and when to close them.

A bug board fails when it grows faster than bugs are fixed. A clear card, a regular triage and a rule for closing keep it small enough to trust.

Web page: https://kansohq.app/guides/bug-tracking-board

Updated: 5 October 2026

## What a bug card needs

A bug that cannot be reproduced cannot be fixed, and a card that makes the fixer ask questions will sit. Every bug card should answer five things.

1. **Summary:** one line saying what is wrong.
2. **Steps to reproduce:** numbered, starting from a clean state.
3. **Expected and actual:** what should have happened, and what did.
4. **Environment:** browser or device, version and the account or data involved.
5. **Evidence:** a screenshot, a recording or the error text.

The [bug report template](https://kansohq.app/templates/bug-report.md) has these ready, so reporters fill in a form, not a blank page.

## Severity and priority are different

Severity is how bad the bug is. Priority is when it gets fixed. A typo on the sign-up page is low severity but may be high priority because every new visitor sees it. A crash in a rarely used export is high severity and may be low priority. Record both, and rank the board by priority.

| Priority | Meaning | Example |
| --- | --- | --- |
| Must | Fix before anything else ships | Users cannot log in |
| Should | Fix in the next planned work | The save button needs two clicks |
| Could | Fix if there is time | A label is misaligned on one screen size |

## Triage on a schedule

Set a fixed time, weekly or twice a week, when someone looks at every new bug. For each one, decide: duplicate, needs more information, accepted and ranked, or declined with a reason. Triage is a decision, not a discussion. Ten minutes is usually enough.

## A board for bugs

A simple set of columns is Reported, Triaged, Fixing, Verify and Done. Put a work-in-progress limit on Fixing so the team finishes fixes before starting new ones, and make Verify a real step: the person who reported it, or a tester, confirms the fix.

## Keep the board from becoming a graveyard

- Close bugs that have been Could for six months. If they mattered, someone would have raised them.
- Merge duplicates into one card and note the other reports on it.
- Count new bugs and fixed bugs each week. If new outnumber fixed, say so and decide what to do.
- Fix bugs in the same cycle as features, not in a “bug sprint” that never arrives.

## A bug card, filled in

**Bug: sign-up button does nothing on a slow connection**

> **Summary:** tapping Sign up on a slow connection shows no change for several seconds, and people tap again.
> **Steps:** 1. Throttle the connection to slow 3G. 2. Open the sign-up page. 3. Fill in the form. 4. Tap Sign up.
> **Expected:** the button shows that it is working, and the form cannot be sent twice.
> **Actual:** nothing changes for about six seconds, and a second tap creates a second request.
> **Environment:** web, current release, Chrome on Android, slow 3G.
> **Priority:** Should. New visitors meet this on their first visit.

## Bugs that come from customers

1. Thank the customer, and say what will happen next, even if it is only “we have it”.
2. Reproduce it yourself before you file it. A customer’s description is a starting point, not a report.
3. File it with the customer’s words and the steps you used to reproduce it.
4. Tell the customer when it is fixed. This costs nothing and earns a great deal.

## Find the cause, not just the fix

When a bug turns out to be serious, ask how it got through. Was there a test that should have caught it? Was the requirement unclear? Was the change too big to review? Fixing the bug repairs one case. Fixing the reason repairs the next hundred. For serious ones, write a short [postmortem](https://kansohq.app/guides/how-to-write-a-postmortem.md).

## A bug board in Kanso

Each bug is a card on a [Kanso board](https://kansohq.app/product/boards.md) with an owner, a due date and a priority of Must, Should or Could. Write what “fixed” means as the card’s acceptance criteria, and the card shows how many are met. Paste a card into [team chat](https://kansohq.app/product/chat.md) and the message shows its current status, so a thread about a bug never goes stale.

## Questions

### What should a bug report include?

A one-line summary, numbered steps to reproduce, what was expected and what happened, the environment, and a screenshot or error text.

### What is the difference between bug severity and priority?

Severity is how bad the bug is. Priority is when it gets fixed. A cosmetic bug on a busy page can be low severity and high priority.

### How often should bugs be triaged?

Weekly at least, and twice a week for a busy product. The aim is that no new bug waits long without a decision.

### When should a bug be closed without fixing?

When it cannot be reproduced after a fair attempt, is a duplicate, or has sat at the lowest priority for months. Close it with a reason, and reopen it if it returns.

## Keep reading

- [What is a kanban board? A guide for software teams](https://kansohq.app/guides/what-is-a-kanban-board.md): A kanban board shows work as cards moving through columns. Learn how it works, how it differs from scrum and how software teams use it well.
- [The MoSCoW method: Must, Should, Could explained](https://kansohq.app/guides/moscow-prioritization.md): The MoSCoW method sorts work into Must, Should, Could and Won’t. Learn what each means, how much to put in Must and how software teams use it.
- [How to write a blameless incident postmortem](https://kansohq.app/guides/how-to-write-a-postmortem.md): A blameless postmortem explains what broke, why and what changes. Learn the sections, how to write the timeline and root cause, and an example.
- [Bug report template: steps, expected, actual | Kanso](https://kansohq.app/templates/bug-report.md): A bug report template with a summary, steps to reproduce, expected and actual results and an environment table. Copy it, or start it in Kanso.
- [Blameless incident postmortem template | Kanso](https://kansohq.app/templates/incident-postmortem.md): A blameless incident postmortem template with a summary, impact table, timeline, root cause and actions. Copy it, or start it in Kanso.

## Parts of Kanso used

- [Kanso Boards](https://kansohq.app/product/boards.md): A board for each piece of work. Cards carry a priority, an owner, a due date and the criteria that say when they are done.
- [Kanso Chat](https://kansohq.app/product/chat.md): Channels and direct messages that link straight to the task, page or release being discussed.

[Kanso home, with plans and prices](https://kansohq.app/index.md)