Bug Tracking Template
A board built for defects, not features: triage by severity, a place for bugs nobody can reproduce yet, and a deliberately tight limit on how many are open at once.
Severity sets the queue order. The WIP limit stops "in progress" from becoming a graveyard.
Why bug boards turn into graveyards
Feature work and defect work behave differently, and a board built for one handles the other badly. Bug boards fail in their own specific way, and the failure is usually visible in one place: a long "in progress" column full of items that haven't moved in two weeks and nobody quite wants to touch.
Severity gets decided by whoever files the ticket. Without a triage step, a typo report and a checkout outage sit at the same visual weight, and the board can't tell anyone which to look at first. The loudest reporter, not the worst impact, ends up setting the queue.
Unreproducible bugs clog "in progress." A developer spends an hour failing to reproduce something, doesn't want to close it as invalid, and it sits half-open indefinitely, occupying a slot that a real, actionable bug needs. Three or four of these and the column stops meaning anything.
Nothing stops new bugs from being started before old ones finish. Without a tight limit specifically on active work, engineers context-switch between five half-fixed bugs and none of them ship this week. This template caps "in progress" harder than a feature board would, because half-fixed bugs are worse than half-built features: they're often still live in production, actively affecting users while the fix sits unfinished.
A fix ships without confirming it actually fixed anything. The pull request merges, the ticket closes, and three weeks later the same bug is reported again by a different customer, because nobody checked the fix against the environment where the bug was originally seen.
The structure, and why each part is there
Every incoming report gets a severity before it goes anywhere else, so the queue order is a decision, not a coincidence of filing time. A production outage and a cosmetic misalignment never compete for attention on equal footing again.
A real destination for bugs that don't reproduce on the first attempt, separate from "in progress," so they don't block a slot while waiting on more information from whoever reported it.
Set lower than a feature board's limit on purpose: three open fixes per developer at most is a reasonable ceiling, not a starting suggestion.
A bug card tied to a GitHub branch moves when the fix branch does, and closes when the pull request merges, so "fixed" on the board means merged in the repo, not merged in someone's head three days before the PR actually went up. That's usually the change teams notice first: the reopened-bug count starts dropping once "fixed" only means one thing.
A merged fix isn't done until someone confirms it in the environment where the bug was actually seen. Skipping this step is how the same bug gets reopened two weeks later.
When a fix needs input from someone else (a repro case, a staging credential), one tap raises it with the context attached, instead of the bug sitting silent in the queue while everyone assumes someone else is on it.
Every bug not currently in progress is still sorted by severity, so the next item to pull is always obvious rather than being whatever's at the top of an unsorted list.
How to use it
- 01Define your severity levels before the first bug comes in. Three or four levels, written down on the wiki where everyone can see the definitions, beats an argument about priority on every single ticket.
- 02Set the In Progress limit per person, not per team. Two or three active fixes per developer is usually the right number; five is not a limit.
- 03Move anything unreproduced after one attempt into Can't Reproduce, with a note on what was tried, rather than leaving it stalled in the active column.
- 04Link the fix branch to the card so the column reflects the merge, not someone's memory of having fixed it.
- 05Don't close from the merge, close from verification. A merged PR and a confirmed fix are not the same event.
- 06Review the Can't Reproduce column weekly, not never. Some of those bugs will reproduce eventually with better information; the rest are candidates to actually close.
A board built this way tends to look worse before it looks better. Severity makes visible how many high-impact bugs were previously buried among low-impact ones, and the WIP limit exposes how much was quietly in progress at once, often more than the standup ever let on. That's the point. An honest bug board is more useful than a comforting one.
For a team fixing bugs on the side of feature work, it also helps to be explicit about how much of a sprint's capacity is reserved for fixes versus new work. Without that split decided in advance, bug fixes either eat the entire sprint reactively or get pushed indefinitely because there was never a slot planned for them in the first place.
- Severity decided at triage beats severity decided by who complained loudest
- Can't Reproduce needs its own column, or it quietly clogs In Progress
- Keep the WIP limit on active fixes tighter than you would on feature work
Common questions
That template is built around sprints and sized feature work, with a backlog that gets planned a sprint at a time. This one is built around severity, reproducibility, and a much tighter cap on active work. That shape fits defects better than a sprint board does, especially for a team fixing bugs alongside feature work rather than instead of it, where a critical bug can't wait for the next planning session.
Yes. Most teams run a bug board and a feature board as separate projects in the same workspace, both linked to the same repo, so severity-1 issues don't get lost in a sprint backlog and the two kinds of work don't get sized or prioritized against each other on the same scale.
Not necessarily, and the template doesn't force them together. Severity describes impact, priority describes what gets worked on next, and teams that conflate the two tend to under-fix low-severity issues that happen to be loud. Columns and labels are editable either way.
Yes, along with every other template. Free covers up to five users and two projects with no time limit, which is enough for most small teams to run a real bug board on. See pricing for larger-team plans.
Close it as a duplicate and link it to the original card during triage, ideally before it ever reaches In Progress. Catching duplicates at triage keeps the WIP limit from being spent on the same fix twice under two different ticket numbers.
Related pages
See it on your own work.
A workspace your whole company will actually use is 60 seconds away. No card, no risk, nothing to install.
14-day full-access trial · sample project included · no card required