Features, enhancements and bugs: a simple way to organise work
Almost all work is adding something, improving something or fixing something. That is the method, and it is where the name fenbs comes from.
6 min read
The simplest useful way to organise a list of work is to sort every task into one of three kinds: a Feature adds something new, an Enhancement improves something that already exists, and a Bug corrects something that is broken. Three kinds, and no fourth. That is the method behind fenbs, and it is the name too: fenbs is short for Features, Enhancements and Bugs.
This piece explains why three is the right number, how to decide between them when it is not obvious, and how the rest of the board is built to match.
Add, revise, correct
The idea is older than software. A draughtsman marking up a drawing uses different pencils for different jobs: one to add, one to revise, one to correct. fenbs borrows that directly. On the board, blue is a Feature, green is an Enhancement and red is a Bug.
- Feature. It does not exist yet. “Export the board as CSV.”
- Enhancement. It exists and works, and should be better. “Add keyboard shortcuts.”
- Bug. It exists and does not work as it should. “Payment webhook drops the currency.”
The three are useful because they are about the work’s relationship to what already exists, not about who asked for it, how big it is or which team owns it. That makes them stable. A task’s size changes as you learn more; whether it is new, better or broken rarely does.
Why not more kinds?
It is tempting to add “chore”, “research”, “question”, “idea”. Each seems harmless. The trouble is that every extra kind makes every filing decision slower, and makes the kinds less meaningful as a group. With three, anybody can file a task correctly without training: a developer, a client, a tester on their phone, a site foreman. With eight, people pick the first one that looks roughly right, and the label stops telling you anything.
On fenbs there is no fourth kind and there will not be one. The same reasoning is why there are no epics, sprints, story points, custom fields or automations. Simplicity is the product, not a limit on it.
Deciding between them
Most tasks sort themselves. For the ones that do not, three questions settle it.
- Does the thing exist today? If not, it is a Feature.
- If it exists, does it do what it was meant to do? If not, it is a Bug.
- If it exists and works as intended, but should be different or better, it is an Enhancement.
The classic argument is between a bug and an enhancement: the person reporting says it is broken, the person who built it says it works as designed. Do not spend long on it. Pick one and move on, because on fenbs changing your mind is cheap. Change the kind and the ref changes with it, BU-014 becoming FE-014 or EN-014, while the number stays the same. The letters are worked out when the ref is shown, not stored, and lookups match on the digits, so anything that quoted the old ref still finds the task.
Colour means kind, never urgency
On many boards red means “late” or “urgent”. On fenbs colour is only ever the kind of task. A board full of red reads as “a lot of bugs”, and never as “a lot of urgency”.
That gives you an honest picture of where effort is going. If Next Up is a wall of red for the third week running, you are paying down problems rather than building. If it is all blue, you may be building on top of things that need attention. Neither is wrong, but you can only choose if you can see it.
Status is carried by position, in four lanes: To Do, Next Up, In Progress, Completed. Urgency is carried by priority, from 1 to 10 where 1 is the most urgent. Three questions, three separate answers: what kind of work is it, where is it, and how soon does it matter.
The kind is in the name
Every task gets a ref whose letters come from its kind: FE-014, EN-015, BU-016. You can tell what sort of task someone is talking about from the ref alone. Numbers are unique per board and never reused, even after a delete, so a ref in a commit message or a text to a client means the same task for good.
The rest of the method
The three kinds sit inside a vocabulary of four words, and that is all there is to learn.
- Board: a whiteboard with everything you need to do and everything you have done.
- Task: one thing to do. A Feature, an Enhancement or a Bug.
- Lane: the status of the task. To Do, Next Up, In Progress or Completed.
- Member: somebody who can see the board; a person, or an AI assistant working on a person’s behalf.
A working week looks like this. Anyone writes a task in one line and gives it a kind. At triage you check the kind, set a priority, and pull what matters into Next Up. Work moves through In Progress to Completed. Everything that changes has a name against it, whether a person made the change or an AI assistant did. How it works shows it in five steps.
Why this suits AI assistants
An AI assistant connected to the board benefits from the same clarity people do. A Bug tells it something is wrong and needs correcting. A Feature tells it something new is wanted. “Take the next thing in Next Up” is an instruction with one meaning. When an assistant files a task itself, it has three kinds to choose from, not thirty. Assistants connect over MCP with a token that can never do more than the person who issued it; the connection guide has the steps.
Trying it on your own list
Take whatever list you have now and mark each line F, E or B. It takes a few minutes and usually shows something: far more bugs than you thought, or a pile of enhancements hiding a missing feature. If you then want it on a board, paste it into Add many with bug:, feature: or enhancement: at the start of each line.
feature: Export the board as CSV enhancement: Add keyboard shortcuts bug: Payment webhook drops the currency
The method is free to use anywhere. fenbs is simply the board built around it, with roles for the people and assistants who share it. Plans start at $4.99 a month; see pricing.