What a five-person team actually needs from issue tracking

Most advice about issue tracking is written for organisations. It is then applied by teams of five, who inherit a process designed to keep two hundred people from colliding and wonder why it feels like paperwork.

At five people, almost nothing is mandatory. The interesting question is which small set of things are genuinely load-bearing — the ones whose absence you feel within a fortnight — and which are habits picked up from larger teams that cost more than they return.

The test

Before the lists, the test that generates them.

For any field, status, ritual or artefact, ask two questions. Who reads this? And what decision changes depending on what it says?

If a field has no reader, it is a form nobody fills in honestly. If it has a reader but no decision attached, it is a report. Both are fine in an organisation where the reader is a person whose job is to read it. Neither survives contact with a team where everyone who would read it is also the person who would have written it.

Almost everything below follows from applying that test twice.

What is load-bearing

A stable identifier. Every piece of work needs a short key you can paste into a commit message, a pull request title, a chat thread, or a note to yourself, and have it still resolve to the same thing in a year. This sounds trivial and it is the single highest-value thing a tracker does. It is the difference between a conversation that can be found later and one that cannot.

One status column, with few values. Not one per person, not one per project. The whole team should be able to recite the statuses from memory. Four or five is usually right. The moment there are two ways to express the same state — "In review" and "Waiting on feedback" — people pick differently and the column stops meaning anything.

One owner. Not a list of contributors, not a RACI table. One name, so that "who is holding this" is never a question anyone has to ask. Work that is genuinely shared still has one person whose problem it is if it stalls.

The discussion attached to the work. The most expensive thing a small team loses is context: the reason a decision was made, three months after everyone involved forgot. If the discussion lives in chat and the item lives in the tracker, the reasoning is gone. Not because chat is bad, but because chat has no index that survives the week.

A history you did not have to opt into. Who changed the status, when, and what it was before. Nobody wants this until the afternoon they very badly want it. It has to be automatic, because a log people maintain by hand is a log people stop maintaining by hand.

A personal view. Each person needs to see their own open work without constructing a filter. If seeing your own work requires knowing how the query builder works, most of the team will not look at the tracker at all, and the tracker will drift out of date, and then it is a spreadsheet with more steps.

More than one shape for the same data. A board is the right way to run a standup. A list is the right way to plan a week. A table is the right way to read forty items and their fields at once. These are the same work viewed differently, and having to export anything to get the second view is a sign the tool has picked one of them for you.

Seven things. That is a complete tracker for a team of five, and the honest observation is that most of the effort in the category goes into the eighth through hundredth.

What is ceremony at this size

Not wrong — most of these are correct answers to problems small teams do not have yet.

Story points and velocity. Estimation in abstract units earns its keep when the people planning are not the people building, and a number has to travel between them. On a five-person team the planner is in the room. Points there are a translation layer between two parties who are the same party. If you want to know whether a week's work fits in a week, ask the person doing it, in days.

Formal sprint events. The Scrum Guide timeboxes Sprint Planning at a maximum of eight hours for a one-month Sprint, the Sprint Review at four, and the Retrospective at three, with a 15-minute Daily Scrum (scrumguides.org). Those are maxima, not targets, and the Guide itself describes a Scrum Team as "typically 10 or fewer people" — so this is not a case of a big-team framework being misapplied to a small one. The mismatch is subtler. The events exist to manufacture communication that does not otherwise happen. Five people who already talk every day get most of that output for free, and what remains is the schedule rather than the substance.

Multi-level hierarchy. Epics containing stories containing subtasks containing subtasks. Hierarchy is how you keep work legible when no single person can hold all of it. At five people, someone can. One flat list plus a label is usually enough, and it is enormously cheaper to maintain.

Fields for the sake of reporting. Component, severity, environment, customer impact, target release. Each is genuinely useful somewhere. Run the test: who reads it, and what changes? On a small team the answer for most of them is "nobody" and "nothing", and every one of them is a field somebody has to skip past every time they file anything.

A second tool for planning. The roadmap in one place, the work in another, kept in sync by hand. This always begins as a temporary arrangement and never ends as one. If the roadmap cannot be expressed as a view over the actual work, it is going to be wrong within a month, and wrong roadmaps are worse than no roadmap.

Workflow enforcement. Transitions that require an approval, statuses only certain roles can set, mandatory fields blocking a move. These are guardrails against a coordination failure between people who do not know each other. Five people know each other. Guardrails here mostly catch the team.

What actually changes as you grow

The point of naming these as ceremony is not that they never become useful. It is that they become useful for identifiable reasons, and it is worth knowing what the reasons look like so you adopt them when they arrive rather than in advance.

Hierarchy starts paying when no single person can list everything in flight. Estimation starts paying when someone has to make a commitment to a person outside the team. Permissions start paying when contributors join who are not on the core team. Reporting fields start paying when there is a reader whose job is to read them. Each of these is a specific event, not a headcount, and each of them announces itself.

The cost of adopting them early is not the setup — the setup is an afternoon. It is that every convention needs continuous maintenance, and a convention with no current purpose gets maintained badly and then followed inconsistently, and an inconsistently maintained field is worse than no field, because people believe it.

Disclosure

We build a tracker, which makes this list self-serving, so read it as an argument rather than as advice. Kevta is in beta and aims at roughly the seven items above — stable issue keys, full history, board, list, table and calendar views over the same work, and a personal view of your own issues. It has no story points, no sprints, no burndown and no reporting layer, which is a real limitation for anyone who needs those and not a virtue in general.

The part that stands on its own is the test. Take whatever you use now, walk each field and each ritual through "who reads this, and what changes" and be honest about the answers. Most small teams can delete a third of their process in an afternoon and lose nothing at all.