4 ms·

You guys are missing the corollary that low-severity bugs being escalated to high-priority is the edge case. The point is that severity is not ignored; it does

by buu700 7y ago

You guys are missing the corollary that low-severity bugs being escalated to high-priority is the edge case. The point is that severity is not ignored; it does inform the priority. Most of the time there may even be a direct correlation between severity and priority. But other (real-world business) factors also inform the priority; while severity will never change in the absence of new information about the bug, those other factors may change frequently. It doesn't make sense for a PM to reread every single ticket and reassess each one's severity when adjusting priorities, when the developer can just determine that once and record it in the ticket from the start.

chii 7y ago
Perhaps it's a problem of language. Instead of severity, may be it should be technical complexity.
- buu700 7y ago
  Complexity sounds to me like more of an implementation-level concern. e.g. A bug might be critical severity if it wipes the entire production database, but low complexity if the fix is to delete one line of code. And maybe its priority is P1 instead of P0 because the customer said they'll remember how to avoid triggering the behavior but they really need that logo color changed asap for an important demo.
  - chii 7y ago
    The point i was trying to make is that the severity hardly changed the priority, if its user impact is low. But then that means the severity isn't high either! So what's the point of severity?
    - buu700 7y ago
      Where are you getting "hardly" from? In this example, it normally would have been P0 (release-blocker) but was downgraded to P1 (still the second-highest priority) because of a special consideration on the customer's end. The point of severity is that it's an objective metric determined in isolation based on specific technical guidelines that any developer on the team can follow (such as https://www.chromium.org/developers/severity-guidelines https://www.chromium.org/developers/severity-guidelines). Whereas priority is a higher-level determination that isn't purely technical. It's like the difference between body fat percentage and attractiveness. Any "engineer" (doctor with a DEXA scanner) can tell you your BF%, and attractiveness will typically correlate with BF%, but ultimately your "customers" (romantic partners and targets) decide how attractive you are. Not a perfect analogy (priority is still something you'd decide internally, not your customers directly), but hope that clarifies things.

by buu700 7y ago

chii 7y ago

Perhaps it's a problem of language. Instead of severity, may be it should be technical complexity.

buu700 7y ago
Complexity sounds to me like more of an implementation-level concern. e.g. A bug might be critical severity if it wipes the entire production database, but low complexity if the fix is to delete one line of code. And maybe its priority is P1 instead of P0 because the customer said they'll remember how to avoid triggering the behavior but they really need that logo color changed asap for an important demo.
- chii 7y ago
  The point i was trying to make is that the severity hardly changed the priority, if its user impact is low. But then that means the severity isn't high either! So what's the point of severity?
  - buu700 7y ago
    Where are you getting "hardly" from? In this example, it normally would have been P0 (release-blocker) but was downgraded to P1 (still the second-highest priority) because of a special consideration on the customer's end. The point of severity is that it's an objective metric determined in isolation based on specific technical guidelines that any developer on the team can follow (such as https://www.chromium.org/developers/severity-guidelines https://www.chromium.org/developers/severity-guidelines). Whereas priority is a higher-level determination that isn't purely technical. It's like the difference between body fat percentage and attractiveness. Any "engineer" (doctor with a DEXA scanner) can tell you your BF%, and attractiveness will typically correlate with BF%, but ultimately your "customers" (romantic partners and targets) decide how attractive you are. Not a perfect analogy (priority is still something you'd decide internally, not your customers directly), but hope that clarifies things.