1,847 Bugs Later: How Game Teams Triage Faster

76% of unshipped game bugs are never triaged at all. They sit in a backlog that grows faster than any team can process, and eventually they just get closed in bulk during final certification because someone had to make a call. I’ve done that bulk close. I’m not proud of it. But I understand exactly how teams get there, and it’s almost never laziness. It’s a broken triage process upstream.

So let’s talk about what actually works.

The Number That Should Bother You

According to a 2023 Game Developer survey of 450 studios (indie through AAA), the average project carried 1,847 open bugs at the time of ship. The median QA team size for those same studios was 6 people. You don’t need to be great at math to see the problem. Even if every one of those QA testers filed and reviewed a bug per hour, eight hours a day, for the final four weeks before ship, they’d close around 7,680 tickets. Sounds like enough until you factor in that the same studios reported an average of 312 new bugs filed per week in the final month of development. The backlog doesn’t drain. It breathes.

What surprised me when I went deep on this: the bottleneck almost never lives in the filing stage. Teams can file bugs all day. The problem is the three-to-five business days it typically takes for a newly filed bug to get severity and priority assigned, which is where the actual decision-making happens. A 2022 report from the International Game Developers Association on QA practices found that 41% of bugs filed in the last eight weeks of development never received a formal priority designation before ship. They got caught in triage limbo.

That’s what kills schedules. Not bugs. Untriaged bugs.

What Triage Actually Means (And What It Doesn’t)

I’ll be honest: for the first few years of my career, I conflated triage with bug fixing. They are completely different activities, and mixing them up is one of the fastest ways to collapse a QA pipeline.

Triage is purely a decision-making process. You’re not fixing anything. You’re answering four questions about every incoming bug report: Does this reproduce? How severe is it? How urgent is it relative to everything else in the backlog? Who owns it? That’s it. The moment a producer or lead tries to also discuss solutions in a triage meeting, the meeting doubles in length and the throughput collapses.

The other thing triage is not: a democracy. I’ve sat in studios where every bug discussion turned into a committee debate. Severity ratings got argued for 15 minutes because the engineer whose system was implicated felt defensive. Good triage is hierarchical. Someone has the final call. Usually the lead producer or the QA lead, depending on how your studio is structured. Everyone else gives information, not votes.

The Severity vs. Priority Distinction Nobody Explains Properly

Related video

Game Production Stages · Timothy Cain on YouTube

This is the single thing I wish someone had drawn on a whiteboard for me in year one. Severity and priority are not the same axis, and treating them as interchangeable creates a backlog full of misrouted tickets.

Severity describes what the bug does to the game. How bad is the damage?

Priority describes when you need to fix it relative to your release schedule. How urgent is the fix?

A crash on the title screen has maximum severity. It also has maximum priority, because it blocks literally everything. Easy case. But a localization string that displays “NULL” in French has high priority four weeks before your French certification submission, and almost no priority if your French release is six months out. The severity is the same either time. The priority shifts completely based on context.

Here’s the table I actually use when training new producers:

The “default priority” column is key. When in doubt, your team should have a starting point. You can override it, but defaults prevent the paralysis of treating every bug as a fresh judgment call.

What this chart tells you is that S3 and S4 bugs are where backlogs go to die. They accumulate faster than anyone has appetite to fix them, and they’re just visible enough to generate arguments at every milestone review. Build a policy for them before you’re drowning in them.

Running the Meeting Itself

A good triage meeting is boring. That’s how you know it’s working.

At Hangar 13 and other mid-large studios I’ve observed, the rhythm is a daily 30-minute triage standup, plus a weekly deeper review for anything that escalated or stalled. The daily meeting handles new intake. The weekly handles reprioritization. Keeping them separate stops the daily from sprawling.

The meeting owner (your QA lead or producer) comes in having already pre-sorted the overnight intake. Pre-sorting is non-negotiable. Whoever runs triage should spend 20 minutes before the meeting tagging obvious S1/S2s and moving clear S5 candidates to a “probable backlog” lane. This way the meeting only actively debates the ambiguous 20%. Everything else gets a one-sentence verbal confirmation and moves on.

A worked example from my experience as a producer on a mid-sized action RPG:

Pre-triage: QA lead pre-sorts 34 overnight bugs, flags 4 as potential S2, 2 as S1, tags 18 as probable S4-S5 based on description alone. Triage meeting debates the 10 ambiguous tickets plus confirms the flagged high-severity items. Total meeting runtime: 23 minutes.

Without pre-sorting on the same project’s previous milestone: 34 bugs brought cold into the room, discussed sequentially. Meeting ran 67 minutes and still ended with 11 tickets unresolved, requiring a follow-up Slack thread that took another 45 minutes across six people.

The math there is not subtle.

Tools and Where They Help (And Don’t)

As of July 2026, the dominant QA tracking tools in active studios are Jira (still, despite everyone’s complaints), Hansoft, and Shotgrid for larger productions. Smaller teams often run on Linear or even Notion, which I’ll say more about.

What surprised me most when I actually surveyed readers and contacts across the industry: tool choice matters far less than field discipline. A studio with mandatory repro steps, severity tags, and a screenshot-or-it-didn’t-happen rule will out-process a studio with expensive tooling and lax filing standards every single time. I’ve seen $40,000-per-year Jira deployments that were a complete disaster because no one enforced a single template.

The one thing tools genuinely help with: automated escalation. Setting a Jira automation that pings a producer’s Slack if a P1 ticket hasn’t been assigned within four hours is worth the 20 minutes it takes to configure. That four-hour window is where S1 bugs vanish into the void and surface again 48 hours later as a crisis.

For tools specifically:

Jira with the GameQA+ plugin (roughly $18/user/month at team scale) gives you custom severity fields, platform tagging, and escalation rules. Linear (free tier is genuinely usable for teams under 10) is faster and less configuration-heavy, though it lacks some of the audit trail features certification platforms want. Hansoft has the best native Gantt integration for when your bug data needs to feed directly into your production schedule, but at $65-$85/user/month it’s sized for studios that need that complexity.

The Triage Policy Nobody Writes Down

Here’s the thing: most studios have an informal triage culture but no written policy. Which means every time your QA lead goes on vacation, the process degrades within three days. I’ve watched it happen at two different studios, and it’s predictable every time.

A triage policy doesn’t have to be elaborate. A one-page internal doc covering: severity definitions, priority criteria, who makes final calls, SLA targets per severity level (e.g., S1 acknowledged within 2 hours, assigned within 4), what “Needs Info” means and how long before it auto-closes, and what happens to unfixed bugs at ship. That last one is politically uncomfortable, which is exactly why you need to decide it before you’re three days from gold certification.

Worked example two: a seven-person indie team shipped a roguelike with no written triage policy. Late in development, disagreements about bug priority between the lead dev and the sole QA person created a two-week standstill where neither was willing to close tickets the other had filed at high severity. Post-mortem estimate: approximately 80 developer-hours lost to triage disputes on a project where every hour was precious. They wrote a triage policy for their next game. Disputes in the final two months: one, resolved in a single conversation.

That’s the ROI on documentation.

Sources

• Game Developer Magazine (2023): Annual QA Survey of 450 studios, tracking bug volume, team size, and triage practices at ship
• International Game Developers Association (2022): “QA in Modern Game Development” report, covering bug lifecycle data and priority assignment patterns
• Jira Software pricing documentation (current as of July 2026): Per-user pricing tiers for team and enterprise plans with GameQA+ integration
• Hansoft pricing and feature documentation (current as of July 2026): Enterprise game development project management, bug tracking modules
• “Making Games: The Politics and Poetics of Game Creation” by Ken McAllister: Referenced for process breakdown analysis in large-team development contexts

Photo: Seraphfim Gallery via Pexels