How small teams should structure issues, labels, and workflows

Q: How do we handle ideas that aren't committed work?

Keep them out of the backlog. A separate ideas doc (or a someday project reviewed quarterly) keeps the tracker meaning "things we intend to do" - the moment wishes mix with commitments, every list in the tool needs a mental asterisk.

A minimal issue-tracking setup that stays truthful - what states you actually need, which labels earn their keep, how big an issue should be, and the habits that prevent tracker rot.

Mar 27, 2026 · 4 min read · Kash Gohil

Most small teams get issue tracking wrong in one of two directions: a wall of stale tickets nobody trusts, or a Jira-grade process machine for eight people. The right setup is small, boring, and mostly about habits. Here's the structure that works for teams of roughly three to thirty, on any tracker.

How many workflow states do you actually need?

Four. Maybe five.

Backlog - agreed it's worth doing, not started. Not a wish list; that's what "closed - won't do" is for.
Todo / Next - chosen for the current cycle. The only column planning meetings should touch.
In progress - someone's name is on it, work has started. One or two per person, not five.
Done - merged. Not "code written," not "in review" - merged. (Let the merge close it automatically; that link removes most tracker fiction on its own.)

The optional fifth is In review - useful once review latency is a real queue; noise before that. Every state beyond these needs to answer: "what decision does this state help someone make?" "Blocked" as a state usually fails that test - a label or a comment says why, which is the part that matters.

Which labels earn their keep?

Labels rot faster than anything else in a tracker, because adding one is free and maintaining a taxonomy isn't. Three families pay rent:

Type: bug, improvement, chore. Three, not ten - the question this answers is "what share of our work is fixing vs. building?"
Area: the major surfaces of your product (api, app, infra). Keep it to under ~8, matching how your team actually divides work.
Priority - only if you'll honor it. urgent means drop things; if nothing ever gets dropped, delete the label rather than lie with it. Most small teams do better with ordering the Todo column than with priority fields.

Everything else - needs-design, good-first-issue, discussed-in-standup - add only when a recurring, concrete need appears, and delete on the first sign of rot. A label used inconsistently is worse than no label: it makes filters quietly wrong.

How big should an issue be?

The unit that works: one issue = one reviewable change, roughly a day or two of work. Bigger than that, and "in progress" stops meaning anything (in progress on which part?); smaller, and the tracker becomes a to-do list of keystrokes.

Work that's genuinely bigger than a few days is a project (or epic, or whatever your tool calls a group): a container of issues with a goal, ideally traceable to the spec that motivated it. The hierarchy that suffices for a small team is exactly two levels deep - projects contain issues. Sub-tasks of sub-tasks are how trackers become jungles.

Two writing habits that repay themselves daily: a title someone can act on ("Login times out on slow connections" not "Auth problems"), and a first line saying how you'll know it's done.

What habits keep the tracker truthful?

Structure decays without three recurring practices:

Triage weekly, briefly. Fifteen minutes: new issues get typed and either scheduled or backlogged; anything that's been in Backlog for three months gets closed as won't do - it will re-file itself if it matters. A tracker's value is inversely proportional to its stale-ticket count, because staleness teaches people to stop reading it.

Automate the links. Issue references in branches and PRs, auto-close on merge, status flowing back to any originating doc. Every manual status update is one that eventually won't happen - the full argument is in spec to shipped.

Let the tracker answer questions. "What's the state of X?" should be a lookup, not a Slack ping - that's half the point, and the interruptions it saves are worth more than the bookkeeping costs.

In Rezee this is the shape Plan & Track ships with - issues, labels, and workflows living beside the code in Code & Ship, closing on merge, visible in chat unfurls - and it's what lets agents do first-pass triage safely: an agent can label, dedupe, and route new issues because the conventions above are legible structure, not tribal knowledge.

FAQ

What's the best issue tracker for a small team?

The one nearest your code, configured minimally. GitHub Issues, Linear, and Rezee's planning layer all comfortably hold the structure above; Jira does too but defaults heavy. The setup in this post matters more than the logo on it - and if you're weighing consolidation, we compared the shapes in Rezee vs Linear + GitHub.

Should bugs and features live in the same tracker?

Yes, for a small team - one queue, one prioritization conversation, with a bug/improvement type label preserving the distinction. Separate trackers mean the "what do we work on next?" answer lives in two places, which means it lives nowhere.

How do we handle ideas that aren't committed work?

Keep them out of the backlog. A separate ideas doc (or a someday project reviewed quarterly) keeps the tracker meaning "things we intend to do" - the moment wishes mix with commitments, every list in the tool needs a mental asterisk.

How often should we clean up the backlog?

Continuously in small doses: the weekly fifteen-minute triage plus a quarterly sweep that closes anything untouched for three months. If cleanup feels like a project, it's overdue - shrink the interval, not the standards.