How to track bugs and feature requests in one board

Track bugs and feature requests in one board by giving every task a kind, not a separate home. Keep a single list, mark each task as a bug, a new feature or an improvement to something that exists, let the people who spot problems file them directly, and decide what is next in one regular sitting. Two lists always drift apart; one list with a clear label on each task does not.

This is the method fenbs is built around, and the name says so: Features, Enhancements and Bugs. The method works in any tool that lets you label a task, so take the parts that help.

Why separate lists fail

Splitting bugs from feature work feels tidy. In a small team it causes three problems.

• The same people do both kinds of work, from the same hours. Two lists hide the only question that matters, which is what to do next across all of it.
• The boundary is blurry. “The export is confusing” is a bug to the person who reported it and an enhancement to the person who built it. With two lists, it gets filed in neither, or both.
• One list gets looked after and the other rots. Usually the bug list is the one that rots, and the people who reported the bugs notice.

Step 1: one board, three kinds

Give every task exactly one kind.

• Bug: something is broken.
• Feature: something new is wanted.
• Enhancement: something that exists should be better.

On fenbs the kind shows in two places. It sets the colour of the card: blue for a Feature, green for an Enhancement, red for a Bug. And it sets the letters of the ref: FE-014, EN-015, BU-016. Colour never means status or urgency, so a lot of red tells you about the mix of work, not about panic.

When a task was filed as the wrong kind, change it. The ref’s letters change with it, BU-014 becoming FE-014, and the number stays the same. Anything that quoted the old ref still finds the task, because lookups match on the digits.

Step 2: let the people who find problems file them

The people who spot a problem are usually not the people who fix it: your team, your client, a friend testing on their phone. If the only way in is through you, reports arrive as screenshots in a chat thread and emails you forward to yourself.

Give those people a role on the board that lets them file without letting them rearrange your work. The fenbs home page describes two that fit. A Reporter can create tasks and comment, and edit only their own. A Viewer can read and comment. Neither can move your tasks between lanes. Opening the board up is not the same as giving it away.

Ask for one line. “Checkout total is wrong on mobile” is enough to start with. You, or an AI assistant, can fill in the detail later. Every report arrives with a ref, a kind and the name of whoever raised it, so triage is reading a list rather than rebuilding one from four places.

Step 3: triage in one sitting

Let new tasks collect in To Do. Once a week, or more often if the volume needs it, go through what is new and do four things to each.

1. Check the kind. Is this really a bug, or a request dressed as one? Change it if needed.
2. Set a priority. On fenbs it runs from 1 to 10, where 1 is the most urgent, grouped into bands so you can filter by “high”.
3. Add what is missing. A sentence in the note about where it happens and what was expected saves an hour later.
4. Decide whether it is next. If so, move it to Next Up. If not, leave it in To Do. Both are honest answers.

Sort To Do by Newest while you triage so the new arrivals are together, then switch to Urgent to check the top of the list still looks right. Each lane keeps its own sort.

Step 4: keep Next Up short

Next Up is the agreement about what happens next, across bugs, features and enhancements together. Keep it short enough to read in one glance. This is where the single list pays off: you can see that the next five things are four bugs and a feature, and decide whether that is the balance you want, rather than discovering it a month later.

If you use an AI assistant, Next Up is also what makes “take the next thing” a clear instruction. The assistant reads the task, does the work, moves the card and records in plain words what it did.

Step 5: answer the reporter on the task

When someone files a bug, the conversation about it belongs on the task, in comments, not in a separate email thread nobody files. The reporter can see which lane their task is in whenever they like, which replaces most “any news on this?” messages. When it reaches Completed, the trail on the task shows who did what and when.

Grouping without more lists

If you run more than one product or area, resist making a board for each. fenbs has optional projects and categories for this. They are made when you need one: type a new name in the task editor and it exists. Rename one and every task filed under it follows. Delete one and its tasks stay, losing only the label. You can filter the board by either, and “No project” and “Uncategorised” are real answers the board groups by, not gaps.

Bringing in what you already have

If your bugs are in one document and your feature ideas in another, paste them both into Add many. Start a line with bug:, feature: or enhancement: to set the kind for that line; lines without a marker take the kind you chose for the batch. Everything is previewed before it is created.

bug: Photos come out rotated on upload
bug: Checkout total is wrong on mobile
feature: Let me filter the board by project

What this method does not include

There is no severity matrix, no custom bug fields, no automatic assignment rules, and fenbs will not add them. A kind, a priority, a note and a lane cover what a small team needs to decide what to do next. Teams with formal support processes and service-level targets need a dedicated tool for that, and should use one. For everybody else, how it works shows the whole board in five steps, and the docs answer the rest in short pages.