Triage Bugs Priorisation | GitScrum
Créez processus triage bugs efficace avec GitScrum. Classification sévérité, assignation priorité et routage pour cycles résolution rapides.
4 min de lecture
How to manage bug triage and prioritization?
Manage bug triage by creating a structured intake process: bugs enter a Triage column, get severity/priority labels assigned, then move to the appropriate priority queue. Use consistent severity definitions (S1-S4), set SLAs per severity, and assign owners for triage rotation. Review untriaged bugs daily to prevent backlog buildup.
Severity definitions
| Severity | Description | Example |
|---|
| S1 - Critical | System down, data loss, no workaround | Production crash, data corruption |
| S2 - High | Major feature broken, workaround difficult | Login failing, checkout errors |
| S3 - Medium | Feature impaired, workaround exists | Slow performance, UI glitch |
| S4 - Low | Minor issue, cosmetic | Typo, alignment issue |
Priority vs Severity matrix
| Low Priority | Medium Priority | High Priority |
|---|
| **S1 Critical** | - | - | Fix immediately |
| **S2 High** | Fix in 1-2 weeks | Fix this sprint | Fix this week |
| **S3 Medium** | Backlog | Fix next sprint | Fix this sprint |
| **S4 Low** | Won't fix | Backlog | Fix when convenient |
Bug triage workflow:
Bug reported - Enters Triage column Assign severity - S1-S4 based on impact Assign priority - Business urgency Add labels - Component, type, reporter Assign owner - Or leave for claiming Move to queue - Based on priority Track SLA - Monitor time in queue Fix and verify - Standard development flow
Bug triage labels
| Label | Purpose |
|---|
| severity:s1 | Critical severity |
| severity:s2 | High severity |
| severity:s3 | Medium severity |
| severity:s4 | Low severity |
| priority:critical | Fix immediately |
| priority:high | Fix this week |
| priority:medium | Fix this sprint |
| priority:low | When convenient |
| needs-info | Missing reproduction steps |
| cannot-reproduce | Unable to replicate |
| duplicate | Already reported |
Bug triage board
| Column | Purpose | WIP |
|---|
| Triage | New bugs to review | None |
| Needs Info | Waiting for details | 10 |
| Ready | Triaged, prioritized | 20 |
| In Progress | Being fixed | 5 |
| Review | Code review | 5 |
| Testing | QA verification | 5 |
| Done | Fixed and verified | None |
Bug report template
## Bug: [Brief description]
### Environment
- Browser/OS:
- App version:
- User role:
### Steps to Reproduce
1.
2.
3.
### Expected Behavior
[What should happen]
### Actual Behavior
[What actually happens]
### Screenshots/Logs
[If applicable]
### Workaround
[If any exists]
Triage rotation
| Day | Triage Owner |
|---|
| Monday | Developer A |
| Tuesday | Developer B |
| Wednesday | Developer C |
| Thursday | Developer D |
| Friday | Developer E |
Related articles
