3 ms·

> there should be an algorithm that everybody should agree on. An example may be: > - If there is downtime, it’s the top priority of everyone affected > - If

> there should be an algorithm that everybody should agree on. An example may be: > - If there is downtime, it’s the top priority of everyone affected > - If there is an incident, it’s the top priority for an on-call agent > ... Very much agree about this. The trouble with "high priority" and "low priority" etc. is that different people perceive different things as having different urgency and importance. As long as you have >1 person entering tasks, each using their own algorithm to assign priority, a "sort by priority" (the only point in having a "priority" field at all as far as I can see) becomes completely useless. If you use names like "downtime" or "incident" then, as the author writes, everyone can agree. That's the important thing I think. Then a "sort by priority" can yield something meaningful. Plus there's the fact that when you have pages of "highest priority" tickets, managers just create all new tickets at that level, "otherwise they won't get seen and done" (true story) This way of working annoyed me so much I wrote a blog post about it: https://www.databasesandlife.com/priorities/ https://www.databasesandlife.com/priorities/

mytailorisrich 6y ago
"Downtime" as a consequence of an issue is 'severity', not 'priority'. But yes there needs to be a clear and consistent definition of what the different levels of severity mean. This is usually the case because people will quickly notice that it quickly gets messy if everyone makes up their own. But, as I mention in another comment, severity does not directly map to priority. Something like severity x frequency (classic measurement of risk) is already getting close, but ultimately it is often a judgement call based on other business considerations as well.
- JamesSwift 6y ago
  I think you misunderstood his point. He is saying that in his system severity == priority. His article he linked lists out explicitly his buckets. Within a given severity I think its then a judgement call of a product owner to rack-and-stack the issues in priority order, exactly how it would be done for traditional 'P1' - 'P5' grading.
- adrianmsmith 6y ago
  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

"Downtime" as a consequence of an issue is 'severity', not 'priority'. But yes there needs to be a clear and consistent definition of what the different levels of severity mean. This is usually the case because people will quickly notice that it quickly gets messy if everyone makes up their own. But, as I mention in another comment, severity does not directly map to priority. Something like severity x frequency (classic measurement of risk) is already getting close, but ultimately it is often a judgement call based on other business considerations as well.

JamesSwift 6y ago
I think you misunderstood his point. He is saying that in his system severity == priority. His article he linked lists out explicitly his buckets. Within a given severity I think its then a judgement call of a product owner to rack-and-stack the issues in priority order, exactly how it would be done for traditional 'P1' - 'P5' grading.
adrianmsmith 6y ago
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.