---
title: "Bug Triage Workflow | Orangescrum"
description: "How to run bug triage without a two hour meeting. The severity rules, the roles, the queue, and the Orangescrum features that carry each step of the workflow."
canonical: https://www.orangescrum.com/use-cases/bug-triage
---

# Bug Triage Workflow | Orangescrum

> For the complete documentation index, see [llms.txt](https://www.orangescrum.com/llms.txt).

[Home](/) / [Use cases](/use-cases) / Bug triage

Use case

# Bug Triage in _Fifteen Minutes a Day_

Triage goes wrong when every bug is urgent and nobody owns the decision. Fix the rules once, run a short daily queue, and the backlog stops growing.

Available in[Cloud](/pricing "Cloud - included")[Self-Hosted](/self-hosted "Self-Hosted - included")Open Source

[Start Free Trial →](/sign-up?utm_source=website&utm_medium=feature&utm_content=usecase_bug-triage)[Book a Demo](https://calendly.com/orangescrum)

Bug and issue tracking is in Cloud and Self-Hosted · Unlimited users on every plan

## The scenario

Bugs arrive from support tickets, from QA, and from developers noticing things. They land in a list that nobody owns. Every fortnight somebody calls a triage meeting, twelve people spend two hours arguing about severity, and half the list is still untouched at the end. The alternative is a fifteen minute daily pass done by two people, against written rules that were agreed once.

Runs

Daily, or twice a week

Meeting length

15 to 30 minutes

Start from

Bug Tracking project template

Owner

QA lead or engineering manager

Who is involved

## Who is _actually needed_

Two people run triage. Everyone else contributes without attending.

| Role | What they own | What they see in Orangescrum |

| Triage lead | The decision on severity, owner, and target release | The untriaged queue, filtered to defects with no owner |
| Engineering manager | Whether the team has room to take the fix now | The defect board and the current sprint |
| QA engineer | Reproduction steps, environment, and the linked test case | Defects raised against their test cases |
| Support | Customer impact and how many people are affected | The ticket queue, and the defect the ticket was escalated into |
| Developers | Fixing what is assigned, and saying when something is misjudged | Their assigned defects on the board |

The workflow

## Eight steps from _report to closed_

The first two steps are set up once. The rest run every day.

1.  1
    
    ### Write the severity rules down
    
    Agree what critical, high, medium, and low actually mean, in plain sentences, and put them somewhere everyone can read. Without this, severity is whoever shouted loudest.
    
    -   Critical means production is down or data is at risk
    -   High means a core workflow is broken with no workaround
    -   Medium means there is a workaround and it is annoying
    -   Low means cosmetic or edge case
    
    Carried by[Wiki management](/wiki-management)
    
2.  2
    
    ### Make the report form capture what you need
    
    Most triage time is wasted asking for information that should have been in the report. Add fields for environment, affected version, and steps to reproduce, so an incomplete report is obvious immediately.
    
    -   Custom fields mean environment and version are filterable data, not free text buried in a description
    -   In the self-hosted edition, conditional fields can show these only on defect type items
    
    Carried by[Custom fields](/custom-fields)[Bug and issue tracking](/bug-and-issue-tracking)
    
3.  3
    
    ### Everything lands in one queue
    
    Bugs from QA, from support escalations, and from developers all go to the same place with the same status. A defect that lives in somebody's inbox is not tracked.
    
    -   Support tickets that turn out to be defects get raised as a defect and linked back to the ticket
    -   Filter the board to the untriaged status to see the day's queue
    
    Carried by[Bug and issue tracking](/bug-and-issue-tracking)[Ticketing](/ticketing-software)
    
4.  4
    
    ### Run the daily pass
    
    Two people, fifteen minutes, one filtered view. For each item decide three things and move on: is it real, how severe is it, and who owns it.
    
    -   Cannot reproduce goes back to the reporter with a question, it does not sit in the queue
    -   Duplicates get linked to the original and closed
    -   Anything that needs a longer discussion gets one owner and a deadline, not a committee
    
    Carried by[Bug and issue tracking](/bug-and-issue-tracking)[Advanced search](/advanced-search)
    
5.  5
    
    ### Route critical items straight into the sprint
    
    A critical defect does not wait for the next planning meeting. It goes into the current sprint the same day, and something else comes out to make room.
    
    -   Say out loud what is being dropped, so the swap is a decision rather than an accident
    
    Carried by[Agile project management](/agile-project-management)
    
6.  6
    
    ### Match the statuses to how you really work
    
    The default defect flow rarely survives contact with a real team. Add the statuses you need, such as awaiting information or ready to retest, so the board reflects reality instead of a tidy fiction.
    
    -   Statuses can be added from the board or from the status workflow page at any point
    -   The self-hosted edition adds a visual designer for the transitions between statuses
    
    Carried by[Custom status workflow](/custom-status-workflow)
    
7.  7
    
    ### Retest before you close
    
    A defect is not closed because a developer says it is fixed. It is closed when the test that found it passes again, which is why the defect and the test case should be linked.
    
    Carried by[Test case management](/test-case-management)[Defect tracking](/test-case-management/defect-tracking)
    
8.  8
    
    ### Review the shape of the backlog monthly
    
    Once a month, look at where defects come from and how long they sit. If one area produces most of the bugs, that is an engineering conversation, not a triage one.
    
    -   Resolution time and average age tell you whether triage is keeping up
    -   Count by component or environment to find the source
    
    Carried by[Advanced reporting](/advanced-reporting)[Reports and analytics](/project-reports-analytics)
    

Set it up

## Build it _on Monday morning_

Around thirty minutes, most of which is writing the severity rules.

1.  1Create a project from the Bug Tracking templateIt starts the project on a board view with a defect workflow already in place, so there is nothing to configure before the first bug goes in.
2.  2Write the severity definitionsFour sentences. Put them on a wiki page and link it from the project so nobody has to ask.
3.  3Add the fields you keep asking aboutEnvironment, affected version, and browser or device, as custom fields rather than free text.
4.  4Adjust the statusesAdd awaiting information and ready to retest if your team needs them. Do this after a week of real use, not before.
5.  5Name the triage lead and put the meeting in the calendarFifteen minutes, daily, two people. Triage fails when it is nobody's job.
6.  6Set up the monthly reviewOne report, once a month, on resolution time and where defects originate.

The result

## What good _looks like_

Nothing sits untriaged for more than a day

The untriaged queue is empty most mornings because the pass happens every day rather than every fortnight.

Severity means the same thing to everyone

Because it is written down, arguments about severity are rare and short.

The two hour meeting is gone

Ten people got two hours back per fortnight, and the decisions are better because two informed people make them.

Critical bugs are in the sprint the same day

There is a route for urgent work that does not require waiting for planning.

Closed means retested

Defects are closed against a passing test, so reopened bugs become rare.

You can see where bugs come from

The monthly report turns a pile of defects into an engineering priority.

Watch out

## Where this _usually goes wrong_

Everything is critical

Without written rules, severity inflates until the label means nothing.

✓ Four written definitions, agreed once, linked from the project.

Triage by committee

Twelve people in a room means no decision gets made quickly.

✓ Two people with the authority to decide, fifteen minutes a day.

Bugs in three places

Some in the tracker, some in chat, some in a spreadsheet, so the backlog is unknowable.

✓ One queue. A defect that is not in it does not exist.

No reproduction steps

Half the queue cannot be worked on because nobody knows how to trigger it.

✓ Make environment and steps required fields on the report.

Fixed but never retested

Bugs are closed on the developer's word and come back a month later.

✓ Close against a passing test case, not an assertion.

The backlog only grows

Nobody ever declares that a low severity bug from two years ago will not be fixed.

✓ Review the tail monthly and close what you have decided not to do.

Features used

## Everything this _runs on_

[Bug and issue trackingDefects in the same system as the delivery work](/bug-and-issue-tracking)[Custom status workflowA defect flow that matches how you work](/custom-status-workflow)[Custom fieldsEnvironment and version as real, filterable data](/custom-fields)[Test case managementClose a defect against a passing test](/test-case-management)[TicketingEscalate a customer ticket into a defect](/ticketing-software)[Advanced searchFind the queue quickly, in Self-Hosted](/advanced-search)[Advanced reportingResolution time, average age, and origin](/advanced-reporting)[Kanban boardThe daily working view for the queue](/kanban-board)

Frequently asked questions

## Bug triage _FAQ_

How often should bug triage run?

Daily is better than weekly, and much better than fortnightly. A fifteen minute daily pass by two people clears more than a two hour meeting with twelve, because nothing has time to pile up.

Who should attend bug triage?

Two people: someone who can decide severity and priority, and someone who knows the engineering capacity. QA and support feed the queue with good reports, but they do not need to sit in the meeting.

Which template should I start from?

The Bug Tracking template. It creates the project on a board view with a defect workflow already set, so you can start logging bugs immediately and adjust the statuses once you have seen a week of real traffic.

Can I add my own statuses to the defect workflow?

Yes. Statuses can be added from the board or from the status workflow page, and you can switch the project to a different workflow. The self-hosted edition also has a visual designer for the transitions between statuses.

How do I stop everything being marked critical?

Write four severity definitions and link them from the project. Severity inflation is nearly always a definition problem rather than a discipline problem.

Does Orangescrum detect duplicate bugs automatically?

No. There is no automatic duplicate detection and no automatic severity scoring. You link the duplicate to the original yourself and close it, which takes a few seconds during the daily pass.

Can support tickets become defects?

Yes. A ticket that turns out to be a product defect can be raised as a defect and linked back, so support can see the fix progressing without chasing engineering.

Which plan do I need?

Bug and issue tracking is in the Cloud and Self-Hosted editions. Custom fields are on the Cloud Pro plan and above, and in Self-Hosted. Every plan includes unlimited users.

## Get your defect queue under control

Defects, test cases, and delivery work in one system, with unlimited users on every plan.

[Start Free Trial →](/sign-up?utm_source=website&utm_medium=feature&utm_content=usecase_bug-triage_cta)[Book a Demo](https://calendly.com/orangescrum)

## Related use cases

[Sprint planningWhere critical defects land](/use-cases/sprint-planning)[Incident managementWhen it is broken in production](/use-cases/incident-management)[Product launchThe release the fixes ship in](/use-cases/product-launch)[Bug Tracking templateThe project template this starts from](/project-templates/bug-tracking)

[See all use cases →](/use-cases)