Bugs Board — Track and Squash Defects
Bugs left untracked become bugs that slip through. The Bugs board gives defects their own dedicated workspace — separate from feature development, with a workflow focused entirely on identifying, assigning, prioritizing, and resolving problems.
Whether defects come from your QA team, customer support, internal testing, or production monitoring, the Bugs board is where they get tracked to resolution.
Who It's For
The Bugs board is for teams that want to manage defects in a separate workflow from feature development. Common scenarios:
- Support engineers who file bugs reported by customers
- QA teams managing a standalone defect backlog
- Teams who want bugs to have their own sprint cycle and prioritization
- Organizations where a separate team owns bug triage and resolution
Tip: For small teams, a separate Bugs board may be more overhead than it's worth. The R&D board has Bug as a built-in item level — bugs can live right alongside stories in your development workflow. Create a dedicated Bugs board when bugs come from an external source (customers, support) and need a different process, a different team, or separate visibility.
Work Item Hierarchy
The Bugs board supports two levels: Bug → Task.
Bugs
Bugs are top-level items. Each bug represents a single defect — a specific behavior that doesn't work as expected. Bugs include a title, description, reproduction steps, priority, and status.
Bugs are the primary unit of work. Most bugs won't need child tasks.
Tasks
For complex bugs that require multiple pieces of work — investigation, fix, regression testing, documentation update — you can create tasks under a bug. Tasks let you break down the resolution process and assign pieces to different people.
Tasks are optional. Add them when a bug requires enough work that it helps to track steps separately.
Customizing the Hierarchy
The Bug → Task structure is the default. You can configure item level labels and hierarchy behavior to match your team's terminology.
How to customize: Open your board → click the gear icon → Levels tab. Adjust level names and configure which levels are active for your board.
Bug Workflow
The Bugs board uses a focused status workflow designed around the defect lifecycle:
| Status | Meaning |
|---|---|
| New | Just filed — not yet reviewed or assigned |
| Triaged | Reviewed, confirmed as a valid bug, prioritized |
| In Progress | Actively being worked on |
| In Review | Fix written, waiting for code review |
| Ready to Test | Fix merged, waiting for QA |
| Testing | QA is actively testing the fix |
| Fixed | Fix confirmed by QA — resolved |
| Cannot Reproduce | Team was unable to reproduce the issue |
| Not a Bug | Investigated and determined to be expected behavior |
| Won't Fix | Valid bug but team decided not to address it |
| Cancelled | Filed in error or no longer relevant |
The workflow is simpler than the R&D board — it doesn't include deployment stages, pipeline stages, or design status. Bugs move from discovery to resolution without the full ceremony of feature development.
Customizing Statuses
These statuses are the defaults. You can enable only the ones that match your workflow and disable the rest.
How to customize: Open your board → click the gear icon → Statuses tab. Toggle individual statuses on or off, reorder them, and rename them to match your team's language. Each board can have its own status configuration.
Built-In Fields
| Field | Description |
|---|---|
| Status | Where the bug is in its resolution workflow |
| Priority | Urgent, Very High, High, Mid, Low, Very Low |
| Assignees | Developer(s) responsible for the fix |
| QA Assignees | QA team member responsible for verifying the fix |
| Sprint | Which sprint the fix is scheduled in |
| Estimated Hours | Developer effort estimate for the fix |
| Logged Hours | Actual time recorded via time entries |
| Key | Unique identifier (e.g., BUG-23) |
Configuring Built-In Fields
Not every team needs every field. You can enable or disable built-in fields per board to keep the interface focused.
How to customize: Open your board → click the gear icon → Fields tab. Toggle any built-in field off to hide it from views and forms. You can also add custom fields here — text, number, select, date, URL, and more.
Sprint Integration
Assign bugs to sprints and plan fix cycles the same way you'd plan feature work.
- Add bugs to sprints individually or in bulk
- See estimated hours vs. available capacity
- Track fix progress in the sprint board
- Carry over unresolved bugs to the next sprint
Sprint integration is optional — you can run the Bugs board without sprints if you prefer a continuous flow model or just use the priority-based backlog.
Time Tracking
Log hours directly on bugs. Use the built-in timer or enter time manually. Time entries roll up into:
- The bug's logged hours total
- Sprint capacity reports
- Team-level time breakdowns
This lets you understand the true cost of defects — not just count them.
Priority on Bugs
Use priority to distinguish what needs immediate attention from what can be scheduled:
| Priority | When to Use |
|---|---|
| Urgent | Production is down or a critical customer-facing feature is broken |
| Very High | Major bug affecting many users — fix this sprint |
| High | Significant bug affecting some users — schedule soon |
| Mid | Noticeable bug with a workaround — plan it in |
| Low | Minor issue, cosmetic, or edge case |
| Very Low | Nice to fix someday — won't be noticed by most users |
Tip: Reserve Urgent priority for actual emergencies. If everything is Urgent, nothing is. Use Very High for serious bugs and keep Urgent as the signal that something is on fire.
Bugs Board vs. R&D Board Bugs
Lifecycle OS gives you two ways to track bugs. Knowing which to use keeps your workflow clean.
Use the R&D Board's Bug level when:
- Bugs are discovered internally — by the dev team or QA during a sprint
- The bug is closely related to feature work already in the sprint
- You want bugs and features in the same sprint board and velocity tracking
- Your team is small enough that one board handles everything
Use a dedicated Bugs Board when:
- Bugs are filed externally — by customers, support, or monitoring tools
- Bug triage is handled by a different team than feature development
- You want separate prioritization, sprint cadence, or reporting for bugs
- You want bug metrics separate from feature delivery metrics
The two approaches can coexist. Many teams run a Bugs board for customer-reported defects and use the Bug level in their R&D board for internal issues discovered during development.
Default Views
| View | What It Shows |
|---|---|
| All Bugs | Complete bug list, grouped by status |
| Triage Queue | New bugs waiting for review and assignment |
| In Progress | Bugs actively being worked on |
| My Bugs | Bugs assigned to the current user |
| Current Sprint | Bugs in the active sprint |
| By Priority | All bugs sorted and grouped by priority |
| Ready to Test | Bugs waiting for QA verification |
These views are pre-built to cover common bug tracking workflows. You can edit any of them, create new ones, delete ones you don't use, or duplicate a view as a starting point for something custom.
How to customize: Click the gear icon on any view to open its settings. Adjust the display mode, grouping, sorting, visible columns, and filters. Or click + New View in the sidebar to start from scratch.