Orangescrum
Documentation index for AI agents (llms.txt). A markdown version of this page is available at /use-cases/bug-triage.md or by requesting this URL with the header Accept: text/markdown.
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 inCloudSelf-HostedOpen Source
Start Free Trial →Book a Demo

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.
RoleWhat they ownWhat they see in Orangescrum
Triage leadThe decision on severity, owner, and target releaseThe untriaged queue, filtered to defects with no owner
Engineering managerWhether the team has room to take the fix nowThe defect board and the current sprint
QA engineerReproduction steps, environment, and the linked test caseDefects raised against their test cases
SupportCustomer impact and how many people are affectedThe ticket queue, and the defect the ticket was escalated into
DevelopersFixing what is assigned, and saying when something is misjudgedTheir 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 byWiki 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 byCustom fieldsBug 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 byBug and issue trackingTicketing
  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 byBug and issue trackingAdvanced 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 byAgile 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 byCustom 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 byTest case managementDefect 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 byAdvanced reportingReports and 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 workCustom status workflowA defect flow that matches how you workCustom fieldsEnvironment and version as real, filterable dataTest case managementClose a defect against a passing testTicketingEscalate a customer ticket into a defectAdvanced searchFind the queue quickly, in Self-HostedAdvanced reportingResolution time, average age, and originKanban boardThe daily working view for the queue
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 →Book a Demo

Related use cases

Sprint planningWhere critical defects landIncident managementWhen it is broken in productionProduct launchThe release the fixes ship inBug Tracking templateThe project template this starts from

See all use cases →