13 ms·

> a P0 (Blocker) bug is a ship-stopper which has to be fixed before the next release can happen. P1s (Critical) are important but not something we’d stop a rele

• nolok 7y ago
  Because as the quote said, it depends on the client requirement. "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. Your job is not to build the perfect/best product, it's to build the one your client want and is willing to pay money for. The mixup between priority and severity only comes from the modern era when so many product get made for internal consumption, or where the user is not not the buyer.
  • mjw1007 7y ago
    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.)
  • alxlaz 7y ago
    > Your job is not to build the perfect/best product, it's to build the one your client want and is willing to pay money for. So why have severity and priority as two distinct dimensions then? If customer impact is the only relevant metric for your process, why would a bug about which the client says "that's fine for me" ever be considered severe or critical? If the only metric you care about is customer impact, why track two of them?
    • clarry 7y ago
      On the other hand, when you have multiple different users.. One of them sometimes suffers a crash that also loses all their work, and it really pisses them off. That's got to be bad, right? I'd like to call it severe based on its impact to that user. But then the vast majority of your users have never seen that bug, and the bug is damn difficult to track down, so maybe you can't treat it like a stopper.
      • marcosdumay 7y ago
        Then you are back classifying it by impact x probability... What is a different set of dimensions and make much more sense to use basically because filling those 2 dimensions tends to be easier than filling a severity dimension. But that says nothing about why one would want 2 unrelated priority dimensions.
    • lvh 7y ago
      Because severity is usually a general measure (eg, to use an example from application security: XSS is usually a sev:med), but priority can be subject to a bunch of forces not known to the person who found the bug. You might find eg an exploitable dangerouslySetInnerHTML, but if that’s on a separate domain (in the authn and the origin sense), in some back-office page somewhere, it may not be particularly exploitable, the impact of exploitation may not be particularly high, and so may justify a lower priority. Meanwhile, lack of CSRF protection on an endpoint that half the internet is engaged with may be a higher priority, even though CSRF is typically lower sev. Maybe the page with the bad bug is getting shut down next month anyway and we’re just accelerating that instead. Doesn’t make the bug any less bad: definitely makes fixing it less of a priority. (In hindsight I should have used SSRF or SQLi or RCE as examples of the former style bug and XSS as the lower severity of the two to emphasize the difference.)
  • 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.
  • EGreg 7y ago
    That only works with one client When your product is used by many clients you can’t rely on what one client says
  • onion2k 7y ago
    Your job is not to build the perfect/best product, it's to build the one your client want and is willing to pay money for. If you tell the client that they're wrong and that you should fix the critical bug first how they react is a really good test of whether or not they're going to be a good client. If they insist on fixing the lower priority bug first then you should try to stop working with them, because at some point in the future they're going to demand more unreasonable and stupid things that blow up in their face, and you'll lose that client anyway. Save yourself the stress of working with bad clients and get rid of them at the earliest possible opportunity. If they accept that you know what you're talking about and give you agency to fix things in the order that you think they should be fixed, do your absolute best to keep that client happy because they'll be a joy to collaborate with for years.
    • unreal37 7y ago
      > If they insist on fixing the lower priority bug first then you should try to stop working with them I'm all for firing bad clients. Fire the crazy ones. Fire the ones that don't pay. Fire the ones who make ridiculous demands at the last moment. But the client wants you to deploy a fix to the logo ASAP, you do it. That's the client's priority. As long as they accept the disruption to the rest of the work, it's no problem.
• maccard 7y ago
  I think ultimately it boils down to what you want to glean from the data. Not all crashes are mustfix, and some cosmetic issues really are mustfix. If you're trying to assess the priority of two bugs, both are p1, but in your world are marked crash and cosmetic, you would choose the crash. But it might be that the cosmetic but is related to a sponsor/third party/branding/legal issue, which warrants fixing immediately. Having a "cosmetic" tag on that doesn't help you, but a severity of 1 vs a severity of 3 on an edge case crash on shutdown _does_ tell you.
• deleted 7y ago
  [deleted]
• ryandvm 7y ago
  I agree. My experience with the issue is that, while the distinction may exist academically, the reality is that most people don't grok it. The result being that they are so frequently misused that, in practice, they are indistinguishable dimensions. Basically, if what you are trying to do is too complex/nuanced for everybody to understand - don't do it.
• alkonaut 7y ago
  The two values are good to separate if they come from different people/groups. A developer or tester might be good at specifying how severe a bug is: impact (does everyone get it, or just some users) multiplied by frequency (does it happen in commonly used functionality?) multiplied by a category factor (is it a crash, cosmetic, dataloss...) will give you the severity. Some completely different person can come along and give this a high priority because of business reasons, and to prioritize fixing the bug compared to other functionality. Two bugs with the same assigned severity might impact two different markets where the business knows one is critical for the survival of the business, and one is already a safe market. Then it's a priority to fix it. A second reason might be due to ROI (easier severe bugs are better to prioritize than difficult bugs of the same severity).
  • mcfunk 7y ago
    Yes exactly -- it's two different sources of information that one party is not likely to have access to. Severity from a technical-only perspective is important to have. The sense of whether something is easy to fix (which should be size) is also important. Ultimately you could have a low-severity bug, but it impacts a really important customer who cares about it, so it's high priority. This is the most common case I've seen. Severity also can impact whether something gets prioritized at all. If it's low-severity and the business side isn't there either, maybe it just doesn't get done. Whereas something with high severity but low business impact still probably needs to be done regardless or it will lead to bigger problems.
• neandrake 7y ago
  Usually the other orthogonal assessment in addition to severity is frequency. If the bug is unlikely to be seen during regular use then even if severity is high the priority might be lowered. This is usually how risk is managed in my experience.
  • Mertax 7y ago
    Agreed. 1 dimension can represent the impact to an individual user, and the other dimension represents the pervasiveness (frequency) in the user base/market. We have applied the same metric to feature request prioritization. Severity can be thought of as necessity for an individual customer (must have, should have, nice to have, could have, won’t have) and frequency represents an estimation of demand in the market. We even created our own Jira plugin to calculate the product of these and use that number as a self prioritizing index.
• TheMightyLlama 7y ago
  > I don't see the benefit in having severity and priority as 2 distinct dimensions Working directly with PO's both "Technical POs" and "Product POs" I've found that creating a strong distinction between the two as well as what the two dimensions define has a significant impact on the quality of the product over time. In the original post we see that both Priority and Severity are two different dimensions each representing a scale. This is what I think is causing a lot of the discussion in this thread. Because both of these values are a scale we are creating a foundation over which we can get confused and we find ourselves needing to differentiate these two in some way. This comment is a good example of the confused conversations I would often see. All of variations on the same flavour: > If the goal is to better communicate what "type" of bug it is, using an enum classification (eg, cosmetic vs crash vs data-corruption) would be more appropriate than a numeric scale. To get around this in Agile contracts I've always advocated the following: "Severity" scale. Severity of the issue on the user from 1-5. (For Jira users imagine this as your 'Priority' field renamed to severity. 1: The user is unable to complete the journey or part of the journey 2: The user is unable to perform an action, but can complete the journey 3: The user is able to perform an action but... 4: The user is able to perform an action but... 5: The user is able to perform an action but... Of course, you can put in your own definitions. The important thing being that this is defined from the 'users' point of view rather than attempting to define the nature of the issue (crash, freeze, etc...). The nature of the issue can be discussed within the ticket itself. The second dimension 'Priority' instead being thought of as 'Ranking' and is not a field which is added to the ticket. This defines the order in which the issues must be dealt with. Thus allowing a PO to appreciate the severity of an issue and also negotiate with the team it's relative important through ranking.
• pdpi 7y ago
  Priority/Severity is a good, useful way of describing things. Buying clothes detergent because you ran out and have no clean clothes is high priority, low severity. Booking cancer screening sometime this year because you're reaching that age and there's a history of cancer in your family is low priority, high severity.
• deleted 7y ago
  [deleted]
• thunderbong 7y ago
  Like others have mentioned - severity is functional, priority is client specific.
• zouhair 7y ago
  Exactly, if the comma creates a confusion detrimental to the business I call that a severe bug.
• mytailorisrich 7y ago
  As explained, the severity is the impact on the system. For example, a null pointer that causes the system to crash will have a critical severity. But maybe this bug occurs very rarely and in very specific circumstances. On the other hand you have also found another bug that makes your app use bright green Comic Sans. It is not severe as it is only cosmetic. But for some reason, on your last release this happens every time the app is started. It seems likely that the second issue will have a much higher priority and will have to be fixed immediately, while the null pointer can wait. Severity is purely technical. Priority is a project/commercial decision (which is informed by severity but also other considerations). They generally do not align.
• jccooper 7y ago
  Severity can give you a prioritization within priority categories. Fix the severe high-priority bugs first, then the less severe ones, then on to medium-priority. Of course, scheduling is often dominated by other factors, but it gives you a default at least.
• seattle_spring 7y ago
  It's always a scrummaster type who gets back from some training and wants to add a ton of JIRA overhead like separating severity and priority. I've ignored it for 15 years now and it hasn't bit me once.
• dkarl 7y ago
  I agree. To assign a priority, the PM has to know exactly what happens in context. "Severity" doesn't help with that or with any other stage of reporting, tracking, fixing, and testing. I could see where a severity dimension could be useful retrospectively if paired with classification. For example, you could look back and say, why did we have a big spike in severity 1 security bugs in Q4? However, I think I'd rather not have the dimension available than be forced to set it on every single bug on the off chance it will help with analysis later. "I bet we can do cool stuff with this someday" is never a good reason to add process overhead. If somebody retrospectively categorizes and summarizes tickets by some dimension and proves that it yields useful information, that could be grounds for asking engineers to track it in the future.
• TheOperator 7y ago
  Priority is useful for... Prioritization. One can autoassign a priority for an enum classification. I've never seen impact/urgency/severity as being anything other than different ways to say priority or overcomplicated ways to derive priority. Then again I've never wrangled an absolutely massive bug/ticket queue.
• trentnix 7y ago
  I think the benefits are obvious. Lets say you have 10 bugs and they are prioritized in order from 1 to 10. Bugs with the priority 2, 3, and 6 have been given a severity of P0 (a ship-stopper, as the original post described it). Bugs 1, 4, 5, and 7-10 are not considered P0 bugs. Given those priorities and their relative severity, that means the team is committing to deliver, at least, bugs 1-6 prior to the next release. That makes severity a pretty useful dimension to consider on its own and not just as consideration when determining priority.
• epage 7y ago
  On top of what others have said, one case where I've seen value in them being separate is to workaround problems in long gaps between deployments. A bug might be Major or Minor but there is a high risk to fixing it. You might want to do it early in the development process, ahead of higher severity issues, so you get the most runtime on the fix before the next deployment.
• GuB-42 7y ago
  At my work, crashes and even data loss situations are often given low priority and high severity. That's because we just tell the user the workaround and he can keep doing his job. Low severity and high priority can be: - it breaks the software for just one person, but that person is on the critical path. - if breaks users workflow. For example a keyboard shortcut that is used every second stops working. - the bug is an easy, high value fix, so why wait?