How to set up issue tracking in an afternoon

This is for a team of three to fifteen people in one of two situations. Either you have no tracker, and the work lives in Slack threads, a pinned message and one person's notes app. Or you have one and nobody believes what it says, which is the same situation with more clicking.

Most issue tracking setup guides start with the tool. The tool is the part that barely matters. Learning how to set up issue tracking is mostly four or five decisions about your own work, and they are identical whether you end up on Kevta, Linear, GitHub Issues or Trello. Pick something you can undo, then spend the afternoon on the decisions.

What done looks like at the end of the day

• Every piece of live work is in one place. Not every idea — everything someone is doing or has actually promised.
• Each item has one owner and one state, and both are correct today.
• The team has agreed the two or three rules that keep the first two true next week.

The first two are data entry and take about ninety minutes. The third is the whole job.

How to set up issue tracking in eight steps

1. Write down the work that already exists

Thirty minutes, everyone in the room, one shared place. Every piece of work in flight or promised, one line each. A title you would recognise in a week is enough — no descriptions, no estimates, no ordering.

This is a brain dump, not backlog grooming. When someone starts arguing about whether an item is worth doing, write it down and move on; step 8 is where that argument belongs. Ask each person what would stall if they were away tomorrow — that surfaces the work living in one head, which is the work you most need in a shared place.

2. Pick the smallest set of states that changes behaviour

A state earns its place only if somebody behaves differently when an item is in it.

To Do, In Progress, In Review, Done covers most software teams. Add Ready for QA if someone other than the author actually verifies things, then stop. Blocked is usually better as a flag than a state, because moving an item to Blocked erases which stage it was blocked at.

Write one sentence per state, where the team will see it: "In Review means the code is up and waiting on someone who is not the author." Unwritten states drift within a fortnight, into two states meaning the same thing to different people — the failure mode in signs your workflow has too many statuses.

3. Decide where work enters, and what happens to work that arrives elsewhere

Work keeps arriving in chat, in DMs and beside the coffee machine. A tracker only holds if you decide in advance what happens to those.

The rule most small teams land on: anyone can file, and whoever reads a report somewhere else files it before they reply. Not "asks the reporter to file it" — files it.

Tooling helps with the easy half: on GitHub, blank_issues_enabled set to false in .github/ISSUE_TEMPLATE/config.yml means contributors with read or triage access "will only see the configured templates" (docs.github.com). Nothing enforces the half that matters, which is the sentence you say out loud instead: work that is not in the tracker is not work anyone has agreed to do.

4. Give everything an owner

One name per item. Not a list of contributors, not a team label.

The interesting part is the leftovers. "Unowned" is not a placeholder you fill in later — it is a state that needs a decision, and the decision is almost always one of three: someone takes it now, it is explicitly parked with a reason, or it goes in the pile for step 8. Leaving it blank picks a fourth option: it rots on the board, and teaches everyone that the board contains rot.

5. Add only the fields you will read

For every field you are tempted to add, ask who reads it and what decision changes depending on what it says. Priority usually survives that question — it changes what gets picked up next. Severity, component, environment and target release usually do not at this size, and each is one more thing to skip past when filing. That test is the subject of what a five-person team actually needs from issue tracking.

Most trackers ship a sensible default, so the work is resisting additions. A new board in Kevta arrives with Title, Assignees, Status, Priority and Due Date and nothing else, which is this step already done.

6. Wire the transitions you get for free

Boards go stale in the gap between finishing something and recording it. Close that gap by hanging state changes off events that already happen.

If you ship on GitHub, the event is a pull request. GitHub Issues does it with closing keywords in the description — closes, fixes, resolves: "When you merge a linked pull request into the default branch of a repository, its linked issue is automatically closed", and the keywords work only when the pull request targets that default branch (docs.github.com). Linear matches on a magic word or the issue ID in the title and, by default, moves linked issues to In Progress when a pull request is open and Done when it merges (linear.app/docs). In Kevta you copy a ready-made branch name off the issue, the pull request is matched back by issue key with no linking step, and the rule that moves the issue to Done on merge ships switched on — see the quickstart. Off a git-backed tool there is less of this and the budget matters: Trello's free plan includes "250 Workspace command runs per month" (trello.com/pricing).

One automation per event, and only for events you already generate. Automation that depends on somebody remembering something is a second thing to remember.

7. Agree the review habit, with a named person

Fifteen minutes, once a week, one person whose name you say out loud now.

It is not a status meeting. The job is to find what is wrong with the board: items in a state they left three weeks ago, items with no owner, two items that are the same item. Naming a person matters more than the cadence — "the team reviews the board" is how boards stop being reviewed, which is most of the answer to why nobody updates the board.

8. Delete the items you are never going to do

Go back to the list from step 1. Some of it is work nobody will start. Close it now, while the honesty is cheap.

A backlog you will not read is a liability. It buries the live work, it makes every review in step 7 longer, and it teaches the team that most of the board is decoration — after which they stop reading the part that isn't. If deleting feels unsafe, close with a one-line reason; the record survives and the noise does not.

What an afternoon does not fix

Estimation. You will still be wrong about how long work takes. No field, state or view changes that, and a tool implying otherwise is selling you a chart.

A board nobody reads. Setup is the cheap half. If step 7 does not happen, everything above becomes an accurate snapshot of one Tuesday in August.

Maintenance. Every convention needs continuous upkeep, which is what catches careful teams. A field maintained inconsistently is worse than no field at all, because people believe it. That is the argument for the smallest setup that works: less is what survives a busy month.

Disclosure

We build an issue tracker, so treat this with the suspicion any vendor's process advice deserves. The eight steps are the ones we would follow in a spreadsheet, and they work unchanged in Linear, GitHub Issues or Trello.

Kevta is our attempt at making steps 5 and 6 free — a board that arrives with the five fields you will read, and GitHub events that move issues without anyone linking anything. It has no story points, no sprints, no burndown and no reporting layer, which is a real limitation rather than a philosophy. It is in beta, and the Free plan is $0 with 2 workspaces, 5 boards per workspace and 10 members. If you want to try it on the list you write in step 1, put your email on the waitlist.