4 ms·

That doesn't answer the question, which was « Given a specific priority, what additional benefit do you get from having an additional severity label on the bug

That doesn't answer the question, which was « Given a specific priority, what additional benefit do you get from having an additional severity label on the bug? » not « Given a specific severity, what additional benefit do you get from having an additional priority label on the bug? »

kd5bjo 7y ago
The severity is a technical assessment of the issue that the PM, who doesn't necessarily have a technical background, weighs against business needs to establish the priority. Once there is a priority, the severity has already served its purpose.
- thaumasiotes 7y ago
  Why would you weigh the technical "severity" ("what happened?") against the actual severity ("business needs")? The severity, by hypothesis, has no influence on whether you're going to work on the bug or not. You want to weigh the business needs against how easy the bug is to fix, not against what happened as a result of the bug. "What happened as a result of the bug" is purely within the domain of business needs.
  - SamBam 7y ago
    I'm really confused by all this arguing against simply having more information. Is the information about the criticality of the bug (whether or not the app crashes) relevant to the business decision? Yes, of course: "When I press the 'more' button in the developer's bio the app crashes" is a more important bug than "When I press the 'more' button in the developer's bio I don't see more text." Might the criticality of the bug not be relevant to the business decision? Again, yes: "When I press the 'more' button in the developer's bio -- ok, stop, I don't care about this bug." In some cases the criticality is relevant to the business decisions, in others it may not be. It probably usually will be. The app shouldn't crash, because even if it only happens to 1% of people, they're the ones writing reviews on the app store. So the criticality is a big red "Hey! This should probably be high-priority!"-flag, but it's not the only piece of information the PM is going to use.
    - wool_gather 7y ago
      > I'm really confused by all this arguing against simply having more information. I think the argument is that it's not actually more information; it's just smearing out the same information in a way that makes communication and decision making harder. (Note I'm not completely convinced by either side here, just trying to explain.)
    - thaumasiotes 7y ago
      > I'm really confused by all this arguing against simply having more information. What people are pointing out is that you're not arguing for having more information. The "severity" is a marginal zero information on top of the priority. There is no context where you would want to use "severity" instead of priority. So... GIVEN that priority trumps "severity" 100% of the time, AND GIVEN that priority is already being recorded, THEREFORE "severity" has no use, and shouldn't be recorded. What's happening in the post is that someone wondered why there were two fields, and made up a justification for the second field instead of realizing it was a mistake to have two. You can see the mistake happening whenever people choose a word that ordinarily refers to the concept of importance as their label for "severity", while simultaneously acknowledging that "severity" doesn't affect the importance of the issue.
      - daveFNbuck 7y ago
        They're saying that severity informs the decision of how to set priority. I'm not sure why that's necessary since severity is implicit in the description of the bug.
        thaumasiotes 7y ago
        How is severity supposed to inform the decision of how to set priority? That decision is determined by business needs, not "severity".
        SamBam 7y ago
        As I said above > In some cases the criticality is relevant to the business decisions, in others it may not be. It probably usually will be. The app shouldn't crash, because even if it only happens to 1% of people, they're the ones writing reviews on the app store. > So the criticality is a big red "Hey! This should probably be high-priority!"-flag, but it's not the only piece of information the PM is going to use. The point is that PM may be inundated with lots of bugs and new features and other stories that all need prioritization before the next release. If they had a perfect understanding of all of them, they wouldn't need any metadata at all (not even "bug" vs "feature" -- just read the long-form description!), but metadata helps people make decisions. High-severity bugs should generally be prioritized higher, except in cases where PMs have gained a deep understanding of the situation and realize it's not business-critical, and override that. At the point that they set the priority, the criticality is no longer important, just as the "bug" vs "feature" tag is no longer that important once it's been prioritized and assigned.
- marcosdumay 7y ago
  So isn't it useless to make it a cardinal? You are basically throwing information away from a field intended to inform a decision.

kd5bjo 7y ago

The severity is a technical assessment of the issue that the PM, who doesn't necessarily have a technical background, weighs against business needs to establish the priority. Once there is a priority, the severity has already served its purpose.

thaumasiotes 7y ago
Why would you weigh the technical "severity" ("what happened?") against the actual severity ("business needs")? The severity, by hypothesis, has no influence on whether you're going to work on the bug or not. You want to weigh the business needs against how easy the bug is to fix, not against what happened as a result of the bug. "What happened as a result of the bug" is purely within the domain of business needs.
- SamBam 7y ago
  I'm really confused by all this arguing against simply having more information. Is the information about the criticality of the bug (whether or not the app crashes) relevant to the business decision? Yes, of course: "When I press the 'more' button in the developer's bio the app crashes" is a more important bug than "When I press the 'more' button in the developer's bio I don't see more text." Might the criticality of the bug not be relevant to the business decision? Again, yes: "When I press the 'more' button in the developer's bio -- ok, stop, I don't care about this bug." In some cases the criticality is relevant to the business decisions, in others it may not be. It probably usually will be. The app shouldn't crash, because even if it only happens to 1% of people, they're the ones writing reviews on the app store. So the criticality is a big red "Hey! This should probably be high-priority!"-flag, but it's not the only piece of information the PM is going to use.
  - wool_gather 7y ago
    > I'm really confused by all this arguing against simply having more information. I think the argument is that it's not actually more information; it's just smearing out the same information in a way that makes communication and decision making harder. (Note I'm not completely convinced by either side here, just trying to explain.)
  - thaumasiotes 7y ago
    > I'm really confused by all this arguing against simply having more information. What people are pointing out is that you're not arguing for having more information. The "severity" is a marginal zero information on top of the priority. There is no context where you would want to use "severity" instead of priority. So... GIVEN that priority trumps "severity" 100% of the time, AND GIVEN that priority is already being recorded, THEREFORE "severity" has no use, and shouldn't be recorded. What's happening in the post is that someone wondered why there were two fields, and made up a justification for the second field instead of realizing it was a mistake to have two. You can see the mistake happening whenever people choose a word that ordinarily refers to the concept of importance as their label for "severity", while simultaneously acknowledging that "severity" doesn't affect the importance of the issue.
    - daveFNbuck 7y ago
      They're saying that severity informs the decision of how to set priority. I'm not sure why that's necessary since severity is implicit in the description of the bug.
      - thaumasiotes 7y ago
        How is severity supposed to inform the decision of how to set priority? That decision is determined by business needs, not "severity".
        SamBam 7y ago
        As I said above > In some cases the criticality is relevant to the business decisions, in others it may not be. It probably usually will be. The app shouldn't crash, because even if it only happens to 1% of people, they're the ones writing reviews on the app store. > So the criticality is a big red "Hey! This should probably be high-priority!"-flag, but it's not the only piece of information the PM is going to use. The point is that PM may be inundated with lots of bugs and new features and other stories that all need prioritization before the next release. If they had a perfect understanding of all of them, they wouldn't need any metadata at all (not even "bug" vs "feature" -- just read the long-form description!), but metadata helps people make decisions. High-severity bugs should generally be prioritized higher, except in cases where PMs have gained a deep understanding of the situation and realize it's not business-critical, and override that. At the point that they set the priority, the criticality is no longer important, just as the "bug" vs "feature" tag is no longer that important once it's been prioritized and assigned.
marcosdumay 7y ago
So isn't it useless to make it a cardinal? You are basically throwing information away from a field intended to inform a decision.