4 min read • Guide 562 of 877
How to Use GitScrum for Bug Tracking and Triage?
How to use GitScrum for bug tracking and triage?
Use GitScrum for bug tracking by creating tasks with "bug" labels, setting priority and severity labels, and using a triage workflow. New bugs enter Backlog, get triaged for priority, then flow through development columns. Teams with structured triage reduce bug resolution time by 35% [Source: Software Quality Research 2024].
Bug tracking workflow:
- Report bug - Create task with details
- Label - Add type-bug, severity
- Triage - Assess priority
- Prioritize - Place in backlog
- Fix - Development workflow
- Verify - QA confirmation
- Close - Mark Done
Bug report template
| Field | Content |
|---|---|
| Title | Clear bug description |
| Steps to reproduce | Numbered steps |
| Expected behavior | What should happen |
| Actual behavior | What happens |
| Environment | OS, browser, version |
| Screenshots/logs | Visual evidence |
Bug labels
| Category | Labels |
|---|---|
| Type | type-bug |
| Severity | sev-1, sev-2, sev-3, sev-4 |
| Priority | priority-p1, priority-p2, etc. |
| Area | component-frontend, etc. |
| Status | needs-info, confirmed, wont-fix |
Severity definitions
| Severity | Definition |
|---|---|
| SEV-1 | System down, no workaround |
| SEV-2 | Major feature broken |
| SEV-3 | Minor feature issue |
| SEV-4 | Cosmetic, low impact |
Priority vs Severity
| Aspect | Severity | Priority |
|---|---|---|
| Measures | Technical impact | Business urgency |
| Set by | Technical assessment | Product decision |
| Changes | Rarely | Based on context |
| Example | High severity, low priority: rare edge case |
Triage meeting agenda
| Item | Time |
|---|---|
| Review new bugs | 5 min |
| Assign severity | 5 min |
| Set priority | 5 min |
| Assign owner | 5 min |
| Update backlog | 5 min |
Bug workflow columns
| Column | Purpose |
|---|---|
| Triage | New bugs |
| Backlog | Prioritized bugs |
| Ready | Ready to work |
| In Progress | Being fixed |
| Testing | Verification |
| Done | Resolved |
Bug allocation strategy
| Capacity | Allocation |
|---|---|
| Features | 70% |
| Bugs | 20% |
| Tech debt | 10% |
Critical bug escalation
| Scenario | Action |
|---|---|
| SEV-1 reported | Immediate notification |
| No owner | Assign on-call |
| Blocked | Escalate to lead |
| Long open | Review in standup |
Bug metrics to track
| Metric | Purpose |
|---|---|
| Open bug count | Backlog health |
| Bug age | Resolution speed |
| Escape rate | Quality indicator |
| Time to fix | Development efficiency |
| Reopen rate | Fix quality |
Preventing bug accumulation
| Practice | Implementation |
|---|---|
| Regular triage | Weekly minimum |
| Bug budgets | Sprint allocation |
| Won't fix decisions | Close low-value |
| Root cause | Prevent recurrence |
Bug documentation
| Document | Content |
|---|---|
| Triage criteria | How to assess |
| Severity guide | Definitions |
| Escalation | When and how |
| Workflow | Process steps |