u/mr_hunt_

Been thinking about this a lot lately and I don't see it discussed enough.

Everyone talks about severity inflation as an annoyance engineers file everything Critical, the priority column becomes noise, PMs re-rank manually before every sprint. Frustrating, sure. But the actual cost runs deeper than lost time in sprint planning.

Here's what I think is actually happening over 6 months of inflated priorities:

You're shipping the wrong things. When everything is Critical, nothing is. The bugs that actually hurt paying customers the ones that silently corrupt data, that block key workflows, that churn enterprise accounts get lost in a sea of P1s filed by engineers who just wanted their ticket looked at.

Your backlog stops being a planning tool. After a few sprints of political triage, the backlog reflects who complained loudest, not what matters. At that point it's not a backlog it's a graveyard with bad metadata.

Stakeholder trust erodes. Sales stops believing the PM's priority calls because they've seen them get overridden. Engineering stops caring about severity labels because they know they're meaningless. Everyone stops using the system as intended and starts working around it.

The compounding effect: each sprint of bad triage makes the next one harder. You inherit the previous sprint's inflated backlog on top of new tickets. The signal-to-noise ratio gets worse over time, not better.

Curious if anyone has tried to actually quantify this, either the time cost or the downstream impact on retention or churn. Or is this just something teams accept as background noise?

Every sprint it's the same. We sit down to plan, open the backlog, and half the bugs are marked Critical or P1. Engineers file them that way because they know P3s never get looked at. Sales escalate whatever their biggest customer complained about last week. And I'm left re-ranking everything manually before we can even start the conversation.

The result: sprint planning turns into a negotiation instead of a decision. Half the time we're not even talking about what to build we're arguing about whose bug matters more.

What actually helped us was switching the triage question from "how severe is this?" to "what breaks for a paying customer if this ships?" That one reframe cuts through the politics faster than any priority matrix I've tried. A bug that crashes the app for free users drops. A bug that silently corrupts data for enterprise accounts rises even if it was filed as Medium.

Curious if others are dealing with the same thing. How does your team handle severity inflation? Do you have a framework that actually sticks, or does it devolve into whoever shouts loudest?

Asking because we've gone back and forth on this three times in two years and I don't think we've landed anywhere good.

Current setup: support triages inbound, assigns severity based on customer impact, engineering reviews and adjusts based on effort, PM has final call on priority for the sprint. In theory clean. In practice everyone disagrees at every handoff and the PM (me) ends up just making a unilateral call to end the meeting.

The issue is each function is optimizing for something different. Support wants customer pain resolved. Engineering wants to minimize disruption to planned work. PM is trying to balance both against roadmap commitments. None of those are wrong, they just pull in different directions.

I've talked to people at other companies and the honest answer seems to be "whoever has the most context wins" which is not really a process.

Interested whether anyone has found a model that actually distributes ownership in a way that doesn't collapse into one person deciding everything.

Genuine question because I've been thinking about this a lot lately.

We have a severity matrix in our confluence docs. P0 through P4, definitions for each, the whole thing. Spent a whole retro agreeing on it last year.

Doesn't matter. Engineers still file Critical for anything that annoyed them during the build. Support still marks everything affecting a paying customer as P0. The matrix exists and nobody uses it consistently.

I think the problem is the matrix is defined in abstract terms "significant impact to core functionality" and everyone maps their specific situation onto it differently and in good faith arrives at different answers.

What's actually worked for us is switching from severity labels to impact questions at triage time. Not "how bad is this" but "how many users see this, does it block them completing X, is there a workaround." Forces a more concrete conversation.

Curious whether other teams have found anything that actually sticks or whether severity definitions are just destined to drift.