3 ms·
Like I said in my other comment, because it makes the difference between controlled and uncontrolled. Eg "the color is wrong because we specified it wrong" and
by nolok 7y ago
Like I said in my other comment, because it makes the difference between controlled and uncontrolled.
Eg "the color is wrong because we specified it wrong" and "the color is wrong because the app doesn't respect what we ask it to display" both ends up with the same bug (wrong color), same priority, but not the same severity because the second case is uncontrolled.
Severity is a dev tool, priority is a business tool.
- daveFNbuck 7y agoHow does setting a higher severity for one bug over the other help devs?
- ska 7y agoHow would you signal the difference between: 1. We have the wrong .png asset in the database 2. Our entire rendering infrastructure is suspect
- daveFNbuck 7y agoThat would be extremely obvious from the bug title and description, which are presumably being read by the person who sets priority.
- ska 7y agoSo instead of a severity rating, you are saying severity is encoded in the language of the description? Using descriptors a potentially non-technical PM can understand unambiguously? I'm not saying this is the wrong approach by the way, it's just interesting how people approach this differently.
- daveFNbuck 7y agoIf the PM doesn't have enough expertise to understand how severe a bug is, how are they supposed to accurately assess the business impact?