Why do teams disagree about bug priority?

Without a written rubric, every triage meeting becomes a debate driven by who is loudest and what was discussed most recently. Engineers prioritize technical impact, designers prioritize player experience, support prioritizes report volume. A shared rubric forces everyone to use the same criteria.

What dimensions should a bug priority rubric have?

Two dimensions are enough: severity (how bad is the impact when it happens) and frequency (how many players hit it). Multiply or combine them to produce a priority. Adding more dimensions like 'fix complexity' is tempting but pollutes the priority with engineering concerns that belong in scheduling, not triage.

How many priority levels should we use?

Four is plenty: P0 (drop everything), P1 (fix this sprint), P2 (fix this milestone), P3 (backlog). Five or more starts producing collisions where the same bug could fit two adjacent levels and the team argues over which. Four is granular enough for scheduling but coarse enough to be unambiguous.

How to Build a Bug Priority Rubric for Your Team

Quick answer: Use two dimensions (severity and frequency) on simple 1–4 scales, combine them into four priority levels (P0–P3), put the matrix on a single page, and pull it up at the start of every triage meeting. The rubric overrules opinion.

A bug priority rubric is the most underused document in indie game development. Without one, every triage meeting devolves into the same debate: this bug is critical, no it isn’t, the player can work around it, but two players reported it, but it crashes the game, but only on Linux. Hours go by and the priorities reflect whoever argued loudest. A one-page rubric ends the debate before it starts.

The Problem Without a Rubric

When there is no shared definition of P1 versus P2, three things happen.

Inconsistency. The same bug logged twice might be P1 once and P2 the second time, depending on who triages. Reports get re-triaged, work gets reordered, sprints get derailed.

Politics. Whoever cares most about a bug pushes for higher priority. The squeakiest engineer gets their pet bugs fixed first. Design and QA bugs sink because nobody fights for them in the meeting.

Drift. Over months, the meaning of “P1” quietly shifts. By the time you notice, your P1 backlog has 200 items and the term has lost all meaning.

A rubric fixes all three. It is the cheapest possible team improvement.

Two Dimensions Are Enough

Resist the temptation to add fix-complexity, business impact, technical debt, and political sensitivity as separate dimensions. The more dimensions you have, the more things people can argue about. Two is enough: severity and frequency.

Severity is how bad the bug is when it happens to one player. Crash, data loss, blocking, cosmetic. It does not care how many players are affected.

Frequency is how many players hit it. Almost everyone, many, some, few. It does not care what the bug actually does.

Multiplying severity by frequency captures the intuition that a small bug everyone hits is more important than a big bug only one player hits. Other concerns (fix complexity, sprint capacity, marketing implications) belong in scheduling, not triage.

The Severity Scale

S4 - Crash or data loss
     The game crashes, freezes for >30 seconds, or the player loses
     progress that cannot be recovered. Examples: hard crash on
     startup, save file corruption, multiplayer disconnect with rollback.

S3 - Blocking
     The player cannot continue down a critical path. Examples:
     unkillable boss, locked door with no key, tutorial step that cannot
     be completed.

S2 - Significant
     The player can continue, but a major feature is broken or the
     experience is degraded. Examples: wrong item in shop, audio
     missing for a level, achievement does not unlock.

S1 - Cosmetic
     Visible bug that does not affect gameplay. Examples: minor UI
     misalignment, text typo, missing particle effect on one enemy.

Each level has a one-sentence definition and one or two examples. The examples are critical — they make the level concrete instead of abstract.

The Frequency Scale

F4 - Universal
     Affects all or almost all players. Repros on every test rig.
     Examples: bug in the main menu, crash on a common platform.

F3 - Common
     Affects a large fraction (>25%) of players. Easy to repro on
     several test machines but not all. Examples: bug on Intel
     integrated GPUs, regression on Linux.

F2 - Occasional
     Affects a smaller fraction (<25% but >5%) of players. Hard to
     repro deliberately but appears in support reports.

F1 - Rare
     Affects very few players (<5%) or only happens in specific edge
     cases. Examples: bug only on a specific GPU driver version.

The percentages are rough but force the team to think in terms of impact instead of feelings. “A lot of people are reporting it” is replaced by “is it really 25%?”

The Priority Matrix

Combine the two scales into the matrix. Print this on a single page and tape it next to the standup whiteboard.

           F4 (Universal)  F3 (Common)  F2 (Occasional)  F1 (Rare)
S4 (Crash)     P0              P0           P1                P2
S3 (Block)     P0              P1           P2                P3
S2 (Signif)    P1              P2           P3                P3
S1 (Cosmetic)  P2              P3           P3                P3

Definitions:

P0 — Drop everything. Hotfix today. Ship a patch as soon as possible.
P1 — Fix this sprint. Top of the next planning meeting.
P2 — Fix this milestone. Schedule into the next major release.
P3 — Backlog. Fix when convenient or when the area is being touched anyway.

The matrix produces unambiguous priorities. A crash that affects one player on a specific GPU is S4 F1 = P2. A typo on the title screen is S1 F4 = P2. The rubric forces the team to acknowledge that those two bugs deserve roughly equal attention — which is uncomfortable but correct.

Using the Rubric in a Triage Meeting

The rubric does not eliminate triage meetings. It speeds them up. Use this protocol:

Open the rubric on a shared screen.
For each new bug, the triager calls a severity and frequency.
Anyone in the room can challenge with a different rating, but only by referencing the rubric (“this is S3 not S2 because the player cannot continue”).
The matrix produces the priority. Move on.

A 30-bug triage that used to take an hour now takes 15 minutes. The conversation focuses on the few genuinely ambiguous cases instead of the easy ones.

Edge Cases the Rubric Cannot Handle

No rubric is perfect. A few cases need human judgment.

Streamer-affecting bugs. A bug that hits 1% of players but shows up on every Twitch stream may need higher priority than the rubric suggests. Make a note: any bug visible to a streaming audience adds one priority level.

Pre-launch versus post-launch. The rubric is identical, but the threshold for shipping changes. P2 might be acceptable to ship on day one and unacceptable a year in.

Reputation-sensitive areas. Bugs in payments, multiplayer, or save data may justify a one-level bump. Document this exception explicitly.

Keep the exceptions list short. If the exceptions outnumber the rubric, the rubric is wrong.

Maintenance

Review the rubric every quarter. Look at what was actually fixed versus what the rubric said should be fixed. If the team is consistently fixing P2s before P1s, either the rubric is wrong or the team is wrong — figure out which and adjust.

“A bug priority is just a label until the rubric makes it a contract. Without the rubric, P1 means ‘the loudest person said so.’ With the rubric, P1 means something the whole team agrees on.”

Related Resources

For triage workflow itself, see the bug triage meeting guide for game teams. For severity classification specifically, see bug severity classification for game developers. For prioritizing by player impact at scale, see how to prioritize bugs by player impact.

Print the rubric. Tape it on the wall. A rubric in a wiki is a rubric nobody uses; a rubric on the wall is a rubric the team consults.