4 ms·

I must confess I've never really understood the need for "severity" in a task tracking system. As far as I can see, consumers of tickets need to know what orde

I must confess I've never really understood the need for "severity" in a task tracking system. As far as I can see, consumers of tickets need to know what order to do stuff in, and producers and organizers and curators of tickets need to set what order things should be done in. That's "priority" or "urgency". I do understand in a theoretical sense that "Prod system is down" might not always be the absolute highest priority thing to work on. If a particular issue causes a downtime of 1 second every 10 years, it's still downtime, but might not be the most urgent thing to work on. But that's a theoretical example. In my 20 years of software development and managing projects, if the Prod system is down, it's an emergency, and that's what you need to be working on. So "Prod is down" is a useful priority/urgency. At least that's been my experience so far... What am I missing? Are there times when priority and severity are useful as two separate fields?

mytailorisrich 6y ago
Priority vs severity is an all time classic. "Severity" is a measure of how serious the impact of a defect is (Using the term "impact" instead of "severity" can make things clearer). It does not say anything about the priority that should be assigned to fixing it, though it is obviously often correlated. Severity is an absolute metric, priority is a relative metric. In general the person who creates a defect ticket sets its severity based on what has been observed. The priority is set later by project management. > If a particular issue causes a downtime of 1 second every 10 years, it's still downtime, but might not be the most urgent thing to work on. Exactly. There may be a severe issue but because it happens so rarely it is probably not urgent to fix and thus may be assigned a low priority. Of course if the issue "prod is down" is both severe and urgent to solve. But after investigation you may find the root cause and determine that it is costly to resolve while occurring only very rarely and thus that root cause issue may be low priority though it is still high severity. The difference really is useful in practice where the effort and cost of solving issues may not be trivial (large systems and systems involving hardware for example). I have seem severe bugs that were tracked down to ASICs deployed in the field, so very expensive to fix, and for which the fix was deferred to the next product version because it was determined that the issue was rare enough that customers could live with it until then.

mytailorisrich 6y ago

Priority vs severity is an all time classic. "Severity" is a measure of how serious the impact of a defect is (Using the term "impact" instead of "severity" can make things clearer). It does not say anything about the priority that should be assigned to fixing it, though it is obviously often correlated. Severity is an absolute metric, priority is a relative metric. In general the person who creates a defect ticket sets its severity based on what has been observed. The priority is set later by project management. > If a particular issue causes a downtime of 1 second every 10 years, it's still downtime, but might not be the most urgent thing to work on. Exactly. There may be a severe issue but because it happens so rarely it is probably not urgent to fix and thus may be assigned a low priority. Of course if the issue "prod is down" is both severe and urgent to solve. But after investigation you may find the root cause and determine that it is costly to resolve while occurring only very rarely and thus that root cause issue may be low priority though it is still high severity. The difference really is useful in practice where the effort and cost of solving issues may not be trivial (large systems and systems involving hardware for example). I have seem severe bugs that were tracked down to ASICs deployed in the field, so very expensive to fix, and for which the fix was deferred to the next product version because it was determined that the issue was rare enough that customers could live with it until then.