A simple bug triage workflow for small dev teams (6 statuses)
Most dev teams handle bugs the same way: someone reports a problem, it gets dropped into a backlog and it sits there until a developer remembers it exists. The ones that get fixed are the ones someone complained about loudly enough.
That's not a workflow. That's a squeaky-wheel system.
TL;DR: Use six statuses (Reported, Triaged, Scheduled, In Progress, Fixed, Closed) with a Severity custom field to build a bug triage workflow for small dev teams. Run a 15-minute weekly triage meeting to review new bugs, assign severity and decide what gets scheduled. No dedicated triage tool needed.
What is a bug triage workflow?
A bug triage workflow is a repeatable process for evaluating, categorizing and prioritizing incoming bugs before they enter active development. It separates the act of reporting a bug from the decision of when to fix it, so your team works on the right bugs at the right time instead of reacting to whoever reported the issue last.
The word "triage" comes from medicine. Sort patients by urgency before treatment. Same idea applies to bugs. Not every bug deserves immediate attention. Some are cosmetic. Some are critical. Triage is how you tell the difference.
Why most bug triage workflows for small dev teams break down
The typical failure: bugs get reported into the same backlog as features and tasks. There's no severity marker. No status distinguishes "someone just reported this" from "we decided to fix it next sprint." Everything sits in one list and the team picks based on gut feeling.
This causes real problems:
- Critical bugs wait too long. A login crash and a typo sit in the same column. The typo gets fixed because it's quick. The login crash waits because nobody triaged it.
- Duplicate work. Two developers start fixing the same bug independently because nobody claimed ownership during triage.
- Bug reports rot. Without a review step, old bugs lose context. Steps to reproduce no longer apply. You spend time investigating whether the bug even still exists.
A structured triage workflow prevents all of this. Fifteen minutes a week saves hours of wasted effort.
What six statuses does a bug triage workflow need?
Here's a bug triage workflow that works without a dedicated triage inbox or complex automation. It uses six custom statuses that map to real decisions your team makes about each bug.
| Status | What it means | Who acts |
|---|---|---|
| Reported | Bug filed but not yet reviewed | Reporter |
| Triaged | Reviewed, severity set, confirmed reproducible | Triage lead |
| Scheduled | Approved for a specific sprint or work cycle | Team lead |
| In Progress | Developer actively working on the fix | Developer |
| Fixed | Fix merged, ready for verification | Developer |
| Closed | Verified fixed or intentionally not fixing | QA or reporter |
Each status represents a decision point. A bug moves from Reported to Triaged only after someone has confirmed it's real and assigned a severity. It moves from Triaged to Scheduled only after the team decides it belongs in the current or next cycle.
This matters because the gap between "we know about this bug" and "we're going to fix it" is where most workflows fall apart. The Triaged and Scheduled statuses make that gap visible.
Setting up the statuses
In Eigenfocus, go to your project settings and define these six statuses. They immediately become your board columns. Your board will show bugs flowing left to right through the triage pipeline.
You don't need a separate bug-tracking project (though you can have one). If you use custom issue types, set up a "Bug" type that uses these statuses. Your features and tasks can follow a different workflow within the same project.
How does a Severity field improve bug triage decisions?
Statuses tell you where a bug is in your process. Severity tells you how bad the bug actually is. You need both.
Create a single-select custom field called Severity with four options:
| Severity | Definition | Color |
|---|---|---|
| Critical | System down, data loss or security vulnerability | Red |
| High | Core feature broken, no workaround available | Orange |
| Medium | Feature degraded but workaround exists | Yellow |
| Low | Cosmetic issue, minor inconvenience | Green |
The colors matter. When a developer scans the board, a red badge on a card in the Triaged column says "this needs to get scheduled now" without reading the description. Learn more about using field colors in the guide on custom fields every project manager should set up.
Keep severity definitions concrete. "Core feature broken" is specific. "Important bug" is not. Your team should be able to assign severity without a meeting. If two developers would assign different severities to the same bug, your definitions are too vague.
How to run a 15-minute weekly bug triage meeting
A weekly triage meeting is the core of your bug triage workflow for small dev teams. Here's a format that works in 15 minutes or less.
Attendees: 2-4 people. The triage lead (rotates weekly), one developer and optionally the product owner. Don't invite the whole team.
Before the meeting: The triage lead pre-screens the Reported column. Remove duplicates. Flag any bugs with missing reproduction steps and ask the reporter to update them.
The meeting itself:
Review the Reported column (5 minutes). Go through each new bug. For each one: confirm it's reproducible, assign severity and move it to Triaged. If a bug can't be reproduced, add a comment asking for more details and leave it in Reported.
Schedule from Triaged (5 minutes). Look at the Triaged column. Critical and High severity bugs get moved to Scheduled immediately. Medium bugs get scheduled if there's capacity. Low bugs stay in Triaged until someone has time.
Quick status check on In Progress (5 minutes). Any bugs stuck? Any blockers? This isn't a deep discussion. If something needs more time, take it offline.
After the meeting: The triage lead updates the board. Developers pick from the Scheduled column for their next bug fix.
Rotating the triage lead
Rotate who leads triage each week. This spreads the load and means multiple team members understand the full picture of incoming bugs. When one person always triages, they become a bottleneck.
Worked example: triaging 12 bugs on a Monday morning
Your team builds a SaaS product. Over the past week, 12 bug reports came in. It's Monday morning and the Reported column has all 12. Every other column is empty.
Step 1: Review and assign severity (5 minutes)
The triage lead opens each bug, confirms it's reproducible and assigns severity:
- Critical: Login fails on Safari (core auth broken for a major browser)
- High: Dashboard chart shows wrong date range, Export CSV missing last column, Password reset email takes 10 minutes
- Medium: Notification email has broken link, Profile avatar doesn't upload on mobile, Search returns no results for special characters
- Low: Dark mode toggle resets on refresh, Tooltip overlaps sidebar, "Save" button misaligned by 2px, API error message unclear, Keyboard shortcut conflicts with browser default
One bug turns out to be a known browser behavior. The triage lead adds a comment and moves it to Closed as "won't fix." The remaining 11 move to Triaged.
Step 2: Schedule based on severity (5 minutes)
The team has capacity for 4-5 fixes this week. The critical bug gets scheduled first. The three high-severity bugs get scheduled next. One medium bug (notification broken link) gets added because it's a quick fix.
Step 3: Quick In Progress check (2 minutes)
No bugs carried over from last week. Done in under 15 minutes total.
Board state after triage:
| Triaged (6) | Scheduled (5) | Closed (1) |
|---|---|---|
| Dark mode toggle resets | Login fails on Safari (Critical) | Keyboard shortcut conflict (won't fix) |
| Profile avatar mobile | Dashboard chart wrong dates (High) | |
| Search special chars | Export CSV missing column (High) | |
| Tooltip overlap | Password reset slow (High) | |
| API error message | Notification broken link (Medium) | |
| "Save" button 2px |
Five bugs ready for developers. Six triaged and waiting for capacity. One closed. Nobody needs to ask "what should I work on next?"
How does a bug triage workflow fit into your existing project?
Bug triage doesn't need a separate tool. It works within the same project where your features and tasks live.
In Eigenfocus, custom issue types let you separate Bugs from Features and Tasks. Each type can have its own statuses. Your features follow Backlog, In Development, In Review, Done. Your bugs follow the six-status triage workflow. Both live in the same project.
The board groups by status, so you see your bug pipeline as columns. Read more about choosing the right approach in the guide on custom statuses, labels and fields. For setting up statuses that match your workflow, see the guide on how to set up a project workflow from scratch.
See how Eigenfocus works for software development teams.
What should you do when bugs pile up faster than you fix them?
Every team hits this at some point. The Triaged column grows faster than you can schedule fixes. Here's how to manage it.
Set a Triaged column limit. More than 15-20 bugs in Triaged means your severity definitions are too generous or you need to close bugs you'll never fix.
Close bugs intentionally. A "won't fix" decision is still a decision. A 2px alignment issue sitting in Triaged for three months isn't getting fixed. Close it. If someone cares enough, they'll report it again.
Batch low-severity bugs. Dedicate one afternoon per month to Low severity fixes. This prevents the Triaged column from becoming a graveyard.
Review Triaged monthly. Bugs older than 30 days need a decision: schedule or close. Stale bugs waste attention every time someone scans the column.
Common questions about bug triage workflows
How often should a dev team run bug triage meetings?
Weekly works for most teams. If you're shipping frequently or running a public beta, move to twice a week. Daily triage is rarely necessary unless you're handling production incidents. The goal is to keep the Reported column empty by each meeting's end.
What's the difference between bug severity and priority?
Severity measures the technical impact of the bug. A login crash is critical regardless of context. Priority is a business decision about when to fix it. A critical bug in a feature that launches next quarter might be high severity but medium priority right now. For most teams under 10 people, a single Severity field is enough. Add a separate Priority field only when business context regularly overrides technical severity.
Should bugs go in the same project as features?
Yes, for most teams. Keeping bugs in the same project as features gives you one board that shows all work in progress. Custom issue types let you separate bugs from features while keeping them in the same project. You'll see bugs and features on the same board, each following their own workflow.
Do I need a dedicated bug tracker?
No. A project management tool with custom statuses and custom fields handles bug triage well. Dedicated bug trackers add value when you have a QA team filing hundreds of bugs per week or when you need automated integrations with testing frameworks. For teams running a weekly triage meeting on a dozen bugs, your project board is enough.
Who should lead bug triage meetings?
Rotate the role weekly across your development team. This prevents one person from becoming the bottleneck and gives everyone visibility into the types of bugs your product has. The triage lead's job is to pre-screen bugs before the meeting and facilitate the 15-minute session, not to make all the decisions alone.
If your team has outgrown GitHub Issues and needs structured issue types for bugs vs. features, see our guide on when GitHub Issues needs structure.
Set up your bug triage workflow in Eigenfocus
Define six statuses, add a Severity field and run your first triage meeting next Monday. The whole setup takes under five minutes.
You can also read about how teams use Eigenfocus for software development.