10 ms·

> "if you click anywhere in the left half of the screen during the 5th screen all the settings get deleted" might be a very severe/critical bug, but if the clie

by clarry 7y ago

> "if you click anywhere in the left half of the screen during the 5th screen all the settings get deleted" might be a very severe/critical bug, but if the client says "thats fine for me don't worry, but can you fix the wrong color on screen one where the logo is purple instead of fuschia that's not acceptable for my needs" then this one has a higher priority, even though it's much less severe. The problem here is the made-up definition of severity.. basically, you decided that crash or losing settings equals severe and cosmetic stuff equals not severe. Why? I could easily give it a different definition. For example, a crash that nobody cares about is not severe. A small "cosmetic" slip up that can cause big damage to brand is very severe. So I agree with the GP here; why do we need to have a definition of severity that does not align with the things that we care about when it comes to actually fixing things?

kd5bjo 7y ago
They're both measures of importance, but evaluated at different times by different parties. In the article's formulation, the QA engineer sets the severity during the initial investigation based on technical criteria. This is then one of the datapoints that the PM uses during triage to set the priority, which is the controlling value from that point in the process onward.
- clarry 7y ago
  I guess the underlying source of confusion is that they're both measures of severity, but priority is severity from business viewpoint while severity is severity from the affected user's viewpoint. A high priority bug that isn't fixed presumably has severe consequences for business (or it was prioritized wrong). A high severity bug that isn't prioritized presumably has low consequences (severity) for business, but it probably really sucks for the unfortunate user who is affected.
- stickfigure 7y ago
  Maybe this is something JIRA-workflow-specific? Here in pivotal-tracker-land the product manager controls priority by ordering stories in the backlog. There is no need for a separate 'priority' field because that is implicit. FWIW, there's also no explicit 'severity' field; the PM is expected to understand all the factors that make issues important and order the backlog appropriately. If you need more categorization, you can apply arbitrary labels.
tehjoker 7y ago
I think it's helpful to think of how bad a cosmetic issue could be. For example, imagine that it's a big launch of a product people will be using in stores worldwide and the cosmetic issue is that the logo now consistently looks like a sex act because of missing letter or development art left inside the release. Also imagine that that act is relevant to a recent revelation in the news about the CEO's personal life. Which do you think the CEO cares about more, the logo or the fact that it crashes sometimes on an infrequently accessed menu?
rumanator 7y ago
> basically, you decided that crash or losing settings equals severe and cosmetic stuff equals not severe. Why? Because you, as a developer, are clueless regarding business needs, and thus are unaware of why "cosmetic stuff" might be far more important than the risk of deleting someone's user profile. For example, perhaps the color scheme clashes with the one used by your client's main competitor and therefore might leave him vulnerable to lawsuits.
- jayd16 7y ago
  Yes but what is the point of severity _and_ priority? Why not one field that's first estimated by QA and then updated by project manager when the clients needs are known?
  - paulmooreparks 7y ago
    So that they can be tracked independently and reviewed later. As I explain in a comment elsewhere, my company uses an app to generate severity, and it may not be adjusted outside of that. We can then track the number of low or high severity bugs in a delivery regardless of how the customer perceives the impacts of the bugs, using a more-or-less objective measure. We can compare that to the customer's view of the quality of the delivery by using the number of low or high priority bugs.
    - jayd16 7y ago
      Makes total sense and my team does this as well. I think calling the value completely perpendicular to fix priority is hyperbolic. Fix priority should be some combination of severity, frequency, effort and stakeholder desire.
    - daveFNbuck 7y ago
      What benefits do this measurement and comparison provide?
      - paulmooreparks 7y ago
nolok 7y ago
Because one is controlled and the other is not. If the color is indeed the one set by the dev/designer/... and it's juste not the right one, that's a controlled thing, it's not severe. The app is doing what you want it to, you just gave it the wrong instructions. The crash on the other hand is uncontrolled. That's severe, because it's a case where the app is not doing what you want it to. Severity is something for the dev team internally, priority is something for the product manager and business people that the dev team follows. When you start mixing the two in a single thing, the dev specific needs are always what goes out the window first.
munk-a 7y ago
Devs inform a ticket with a severity as a counter balance to bug fixing being purely complaint driven. The business benefits from having someone with a technical eye look at a bug and determine if it really is just a cosmetic issue or may allow system misuse - then the PM should take that severity into consideration along with client complaints when handing out priority.
dwild 7y ago
> For example, a crash that nobody cares about is not severe. That's a bad example, something not severe is not severe... can't argue with that. A crash nobody cares about can be quite severe though, there's quite a bit of crash that has been used to make some of the most important security vulnerabilities. When I tried to reproduce the Dirty CoW vulnerability over a VM in a school setting made the teacher VM crash multiple time, he didn't care about the crash either ;), yet that single vulnerability allowed me to skip 90% of the vulnerabilities he wanted us to try to find. I think your comment point something important that you miss too, different client may have different priority, and you too may. I think severity is closer to YOUR own priority. The severity is the impact this MAY have on your business if it wasn't fixed. Like you said, a small "cosmetic" slip up may be important for our brand, thus severe for us. That "cosmetic" slip up could still not be important for all of our client, like over a one page made to sell, yet still be on top in both priority and severity, because it matters for the next client or the sale team, which does matter to you. > So I agree with the GP here; why do we need to have a definition of severity that does not align with the things that we care about when it comes to actually fixing things? You could say that about many information in a ticket. It is still informative though, maybe it's no longer needed, but at one point it did was relevant and in many case, still is. A ticket with an higher severity is something that you need to put more time on to decide whether it deserve an higher priority. I'll go back to your crash example, why would you works on a crash that nobody care about, why would you see "crash" in the ticket with so many steps to reproduce and believe that this deserve an high priority when it never going to happen? In an ideal world sure you would know 100% of the system and know 100% of the tickets and can understands 100% of the impact of this kind of crash and be able to fit it well in the priority, but let be honest, that ideal world doesn't exist. You have a limited time that you can put on each ticket to decide their priority, you have a limited capacity to understands the impact and everything, you have hundreds of tickets to go through, but something that you can do is see that the high severity set by the developer means that you may need to put more time on that ticket to choose its right priority. Sure once the priority has been set, does the severity matter? That's a much bigger question that I won't try to answer, probably not, but did it matter at one point? It did. Would you remove any information from a ticket because it no longer matter? I sure hope not.

by clarry 7y ago

kd5bjo 7y ago

They're both measures of importance, but evaluated at different times by different parties. In the article's formulation, the QA engineer sets the severity during the initial investigation based on technical criteria. This is then one of the datapoints that the PM uses during triage to set the priority, which is the controlling value from that point in the process onward.

clarry 7y ago
I guess the underlying source of confusion is that they're both measures of severity, but priority is severity from business viewpoint while severity is severity from the affected user's viewpoint. A high priority bug that isn't fixed presumably has severe consequences for business (or it was prioritized wrong). A high severity bug that isn't prioritized presumably has low consequences (severity) for business, but it probably really sucks for the unfortunate user who is affected.
stickfigure 7y ago
Maybe this is something JIRA-workflow-specific? Here in pivotal-tracker-land the product manager controls priority by ordering stories in the backlog. There is no need for a separate 'priority' field because that is implicit. FWIW, there's also no explicit 'severity' field; the PM is expected to understand all the factors that make issues important and order the backlog appropriately. If you need more categorization, you can apply arbitrary labels.

tehjoker 7y ago

I think it's helpful to think of how bad a cosmetic issue could be. For example, imagine that it's a big launch of a product people will be using in stores worldwide and the cosmetic issue is that the logo now consistently looks like a sex act because of missing letter or development art left inside the release. Also imagine that that act is relevant to a recent revelation in the news about the CEO's personal life. Which do you think the CEO cares about more, the logo or the fact that it crashes sometimes on an infrequently accessed menu?

rumanator 7y ago

> basically, you decided that crash or losing settings equals severe and cosmetic stuff equals not severe. Why? Because you, as a developer, are clueless regarding business needs, and thus are unaware of why "cosmetic stuff" might be far more important than the risk of deleting someone's user profile. For example, perhaps the color scheme clashes with the one used by your client's main competitor and therefore might leave him vulnerable to lawsuits.

jayd16 7y ago
Yes but what is the point of severity _and_ priority? Why not one field that's first estimated by QA and then updated by project manager when the clients needs are known?
- paulmooreparks 7y ago
  So that they can be tracked independently and reviewed later. As I explain in a comment elsewhere, my company uses an app to generate severity, and it may not be adjusted outside of that. We can then track the number of low or high severity bugs in a delivery regardless of how the customer perceives the impacts of the bugs, using a more-or-less objective measure. We can compare that to the customer's view of the quality of the delivery by using the number of low or high priority bugs.
  - jayd16 7y ago
    Makes total sense and my team does this as well. I think calling the value completely perpendicular to fix priority is hyperbolic. Fix priority should be some combination of severity, frequency, effort and stakeholder desire.
  - daveFNbuck 7y ago
    What benefits do this measurement and comparison provide?
    - paulmooreparks 7y ago

nolok 7y ago

Because one is controlled and the other is not. If the color is indeed the one set by the dev/designer/... and it's juste not the right one, that's a controlled thing, it's not severe. The app is doing what you want it to, you just gave it the wrong instructions. The crash on the other hand is uncontrolled. That's severe, because it's a case where the app is not doing what you want it to. Severity is something for the dev team internally, priority is something for the product manager and business people that the dev team follows. When you start mixing the two in a single thing, the dev specific needs are always what goes out the window first.

munk-a 7y ago

Devs inform a ticket with a severity as a counter balance to bug fixing being purely complaint driven. The business benefits from having someone with a technical eye look at a bug and determine if it really is just a cosmetic issue or may allow system misuse - then the PM should take that severity into consideration along with client complaints when handing out priority.

dwild 7y ago

> For example, a crash that nobody cares about is not severe. That's a bad example, something not severe is not severe... can't argue with that. A crash nobody cares about can be quite severe though, there's quite a bit of crash that has been used to make some of the most important security vulnerabilities. When I tried to reproduce the Dirty CoW vulnerability over a VM in a school setting made the teacher VM crash multiple time, he didn't care about the crash either ;), yet that single vulnerability allowed me to skip 90% of the vulnerabilities he wanted us to try to find. I think your comment point something important that you miss too, different client may have different priority, and you too may. I think severity is closer to YOUR own priority. The severity is the impact this MAY have on your business if it wasn't fixed. Like you said, a small "cosmetic" slip up may be important for our brand, thus severe for us. That "cosmetic" slip up could still not be important for all of our client, like over a one page made to sell, yet still be on top in both priority and severity, because it matters for the next client or the sale team, which does matter to you. > So I agree with the GP here; why do we need to have a definition of severity that does not align with the things that we care about when it comes to actually fixing things? You could say that about many information in a ticket. It is still informative though, maybe it's no longer needed, but at one point it did was relevant and in many case, still is. A ticket with an higher severity is something that you need to put more time on to decide whether it deserve an higher priority. I'll go back to your crash example, why would you works on a crash that nobody care about, why would you see "crash" in the ticket with so many steps to reproduce and believe that this deserve an high priority when it never going to happen? In an ideal world sure you would know 100% of the system and know 100% of the tickets and can understands 100% of the impact of this kind of crash and be able to fit it well in the priority, but let be honest, that ideal world doesn't exist. You have a limited time that you can put on each ticket to decide their priority, you have a limited capacity to understands the impact and everything, you have hundreds of tickets to go through, but something that you can do is see that the high severity set by the developer means that you may need to put more time on that ticket to choose its right priority. Sure once the priority has been set, does the severity matter? That's a much bigger question that I won't try to answer, probably not, but did it matter at one point? It did. Would you remove any information from a ticket because it no longer matter? I sure hope not.