9 ms·

> basically, you decided that crash or losing settings equals severe and cosmetic stuff equals not severe. Why? Because you, as a developer, are clueless regar

> 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
      We have dozens of customers worldwide for our software packages, and each package is highly customised for each customer's business. The severity measure lets us compare release quality across customers using an objective measurement defined and managed by us. The priority measure lets us refine that comparison per customised packaged. Generally, a release with a lot of high-severity issues will have a lot of high-priority issues (since by a default an S1 is a P1, an S2 is a P2, etc.), but some customers have different requirements, different custom features, and some are just more fussy. If a base release that was customised for multiple customers has an expected number of P1, P2, P3, P4 issues for most customers but a high number of P1 and P2 issues for one particular customer, off of the same number of issues in the base release as measured by severity, then that will stand out in our measurements and we'll dive deeper into that customisation to see what's going on. (Edited mid-stream... accidentally submitted too early.)
- rumanator 7y ago
  FTA, severity reflects "a bug’s impact to the functionality of the system", while priority reflect the "client’s business and product requirements". The point of this system is that high-severity bugs might have lower priority than low-severity bugs if you take business requirements into consideration. Yet, this does not mean that severity should be ignored.
- sankyo 7y ago
  You nailed it. Stick with priority and the right stuff will get fixed. Severity just encourages more debate about what needs to be fixed vs. deferred. Inevitably you will end up with a list of defects which will never be fixed.
Chinjut 7y ago
The person you are responding to is saying, yes, "cosmetic stuff" might be far more important. So it's more important! Why have another dimension of assessment where we label it less important? Why not only have the dimension of assessment that actually matches the clients' needs?
- bluGill 7y ago
  Because there is expressed client needs and real needs. They say they care about this cosmetic thing now so it better be fixed. However you well know that if you don't get this other thing fixed soon internal politics at the client will mean they throw you out. Thus you fix the thing they demand be fixed now (it may only take a few minutes), but you ensure the other things are fixed in the next release even though the client doesn't know they care yet.
  - BeeOnRope 7y ago
    Sure, but you don't need separate priority and severity scales to do that: it's just one priority scale but you just assign the priority not entirely on the clients expressed needs but rather also factoring in your own assessment of their needs.
    - bluGill 7y ago
      You don't need that, but you are not everybody. When you have a large organization having a simple way to capture this type of thing and make it clear what you are talking about matters. Of course it does add complexity. It is the call of each organization which things are important enough to be worth the extra complexity and which are not. Maybe for yours it isn't worth the extra cost - there is nothing wrong with that - but other people have different needs and so they will have different answers. In short, you are wrong in thinking there is a universal right answer.
- nolok 7y ago
  Like I said in my other comment, because it makes the difference between controlled and uncontrolled. Eg "the color is wrong because we specified it wrong" and "the color is wrong because the app doesn't respect what we ask it to display" both ends up with the same bug (wrong color), same priority, but not the same severity because the second case is uncontrolled. Severity is a dev tool, priority is a business tool.
hwillis 7y ago
that's a strong argument for having a single priority... Even (generously, IMO) assuming severity represents a tangible thing like a threat to code quality or system stability/debugging, a developer should not be the one trying to balance those internal demands against a customers priorities. The important thing here is that devs know what needs to be done. Distributing that arbitrarily across two fields obscures that.
wpietri 7y ago
> Because you, as a developer, are clueless regarding business needs Then that's the problem we should fix. Instead of creating an extra database field to capture somebody's incorrect opinion, the people who understand priority should be helping developers know enough to have useful opinions.
- xchaotic 7y ago
  Hiring good programmers who are not too far out on Asperger/ introvert scale is an issue. So you can fix it by letting programmers only worry about the tech part and letting PM prioritise things. I think motivation will not be as high but it is a way to get things shipped and profitable.
  - candu 7y ago
    Speaking as someone with Asperger's who considers himself both a good programmer and capable of navigating / leading cross-functional prioritization discussions, and who likes knowing the context behind his work: maybe you should re-evaluate your assumptions about neuroatypical people. (...and if you're indeed in a position where you're responsible for hiring decisions or performance reviews: strike "maybe" from the preceding sentence.)
    - wpietri 7y ago
      Agreed. Non-neurotypical people may or may not need to approach understanding the context differently than neurotypicals. But it's not like we're incapable of understanding the context!
  - nwallin 7y ago
    I work in a niche field. Not so niche that there isn't a lot of money in it, but niche enough that we need to explain to all of our new hires what we do as a company. For us, it is absolutely 100% necessary to hire domain experts to prioritize bugs and features. It's not a question of incompetent or dense developers, it's a question of things that are not obvious to someone who doesn't have tons of experience in the field. It's a problem that I imagine developers working on Chrome, Call of Duty, iTunes, or Outlook don't have. You can hire recent college grads and expect them to understand what the software does, have reasonably good instincts how to prioritize bugs and put together the right user experience even if the description in the feature request is sparse on details. By the way, I heartily recommend working for such a company. My company works very, very hard to retain people. Someone who's spent ten years getting used to the weird stuff our customers expect is far more valuable than someone with half the pay who needs someone to hold their hand through every single issue. Everyone has their own office, management is extremely permissive about the shit that doesn't matter, there's never deadlines or crunch time, everyone chooses their own work/life balance. (We're hourly, and the expectation is that you work more than forty hours a week and need manager approval if you want to work more than 60 for more than three pay periods in a row) If we want more vacation, we can bank hours and spend it on supplemental vacation. Everything's great.
stronglikedan 7y ago
Playing devil's advocate: Why does the developer need to know why one bug is more important than another, if the priorities are clearly defined? I.e., if the backlog manager sets the priorities according to the customer's/business' needs, then the developer just needs to know that the cosmetic bug has a higher priority than the crash bug, but they don't need to know why the priorities are ordered that way to accomplish their tasks. And if they do want to know for their own knowledge, they can just ask someone who understands the needs, without the need for a more complex set of bug report attributes.
- wool_gather 7y ago
  I agree with your overall point I think, but I find that people in general just work better when they have some context for their task and its priority/relevance. Absent that, they sometimes -- consciously or not -- decide "this is stupid" and either rush to just check it off or slow-walk it by allowing themselves to be distracted by other things.
hu3 7y ago
Developer knowledge of business needs is rarely on the low end of the spectrum. For example in the teams I lead I make sure developers participate on PO + stakeholder meetings as observers. This way when devs fix something or develop a new feature they know first-hand what the business expects. A nice bonus is that the team often gets personal praises from our clients.

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
    We have dozens of customers worldwide for our software packages, and each package is highly customised for each customer's business. The severity measure lets us compare release quality across customers using an objective measurement defined and managed by us. The priority measure lets us refine that comparison per customised packaged. Generally, a release with a lot of high-severity issues will have a lot of high-priority issues (since by a default an S1 is a P1, an S2 is a P2, etc.), but some customers have different requirements, different custom features, and some are just more fussy. If a base release that was customised for multiple customers has an expected number of P1, P2, P3, P4 issues for most customers but a high number of P1 and P2 issues for one particular customer, off of the same number of issues in the base release as measured by severity, then that will stand out in our measurements and we'll dive deeper into that customisation to see what's going on. (Edited mid-stream... accidentally submitted too early.)
rumanator 7y ago
FTA, severity reflects "a bug’s impact to the functionality of the system", while priority reflect the "client’s business and product requirements". The point of this system is that high-severity bugs might have lower priority than low-severity bugs if you take business requirements into consideration. Yet, this does not mean that severity should be ignored.
sankyo 7y ago
You nailed it. Stick with priority and the right stuff will get fixed. Severity just encourages more debate about what needs to be fixed vs. deferred. Inevitably you will end up with a list of defects which will never be fixed.

Chinjut 7y ago

The person you are responding to is saying, yes, "cosmetic stuff" might be far more important. So it's more important! Why have another dimension of assessment where we label it less important? Why not only have the dimension of assessment that actually matches the clients' needs?

bluGill 7y ago
Because there is expressed client needs and real needs. They say they care about this cosmetic thing now so it better be fixed. However you well know that if you don't get this other thing fixed soon internal politics at the client will mean they throw you out. Thus you fix the thing they demand be fixed now (it may only take a few minutes), but you ensure the other things are fixed in the next release even though the client doesn't know they care yet.
- BeeOnRope 7y ago
  Sure, but you don't need separate priority and severity scales to do that: it's just one priority scale but you just assign the priority not entirely on the clients expressed needs but rather also factoring in your own assessment of their needs.
  - bluGill 7y ago
    You don't need that, but you are not everybody. When you have a large organization having a simple way to capture this type of thing and make it clear what you are talking about matters. Of course it does add complexity. It is the call of each organization which things are important enough to be worth the extra complexity and which are not. Maybe for yours it isn't worth the extra cost - there is nothing wrong with that - but other people have different needs and so they will have different answers. In short, you are wrong in thinking there is a universal right answer.
nolok 7y ago
Like I said in my other comment, because it makes the difference between controlled and uncontrolled. Eg "the color is wrong because we specified it wrong" and "the color is wrong because the app doesn't respect what we ask it to display" both ends up with the same bug (wrong color), same priority, but not the same severity because the second case is uncontrolled. Severity is a dev tool, priority is a business tool.

hwillis 7y ago

that's a strong argument for having a single priority... Even (generously, IMO) assuming severity represents a tangible thing like a threat to code quality or system stability/debugging, a developer should not be the one trying to balance those internal demands against a customers priorities. The important thing here is that devs know what needs to be done. Distributing that arbitrarily across two fields obscures that.

wpietri 7y ago

> Because you, as a developer, are clueless regarding business needs Then that's the problem we should fix. Instead of creating an extra database field to capture somebody's incorrect opinion, the people who understand priority should be helping developers know enough to have useful opinions.

xchaotic 7y ago
Hiring good programmers who are not too far out on Asperger/ introvert scale is an issue. So you can fix it by letting programmers only worry about the tech part and letting PM prioritise things. I think motivation will not be as high but it is a way to get things shipped and profitable.
- candu 7y ago
  Speaking as someone with Asperger's who considers himself both a good programmer and capable of navigating / leading cross-functional prioritization discussions, and who likes knowing the context behind his work: maybe you should re-evaluate your assumptions about neuroatypical people. (...and if you're indeed in a position where you're responsible for hiring decisions or performance reviews: strike "maybe" from the preceding sentence.)
  - wpietri 7y ago
    Agreed. Non-neurotypical people may or may not need to approach understanding the context differently than neurotypicals. But it's not like we're incapable of understanding the context!
- nwallin 7y ago
  I work in a niche field. Not so niche that there isn't a lot of money in it, but niche enough that we need to explain to all of our new hires what we do as a company. For us, it is absolutely 100% necessary to hire domain experts to prioritize bugs and features. It's not a question of incompetent or dense developers, it's a question of things that are not obvious to someone who doesn't have tons of experience in the field. It's a problem that I imagine developers working on Chrome, Call of Duty, iTunes, or Outlook don't have. You can hire recent college grads and expect them to understand what the software does, have reasonably good instincts how to prioritize bugs and put together the right user experience even if the description in the feature request is sparse on details. By the way, I heartily recommend working for such a company. My company works very, very hard to retain people. Someone who's spent ten years getting used to the weird stuff our customers expect is far more valuable than someone with half the pay who needs someone to hold their hand through every single issue. Everyone has their own office, management is extremely permissive about the shit that doesn't matter, there's never deadlines or crunch time, everyone chooses their own work/life balance. (We're hourly, and the expectation is that you work more than forty hours a week and need manager approval if you want to work more than 60 for more than three pay periods in a row) If we want more vacation, we can bank hours and spend it on supplemental vacation. Everything's great.

stronglikedan 7y ago

Playing devil's advocate: Why does the developer need to know why one bug is more important than another, if the priorities are clearly defined? I.e., if the backlog manager sets the priorities according to the customer's/business' needs, then the developer just needs to know that the cosmetic bug has a higher priority than the crash bug, but they don't need to know why the priorities are ordered that way to accomplish their tasks. And if they do want to know for their own knowledge, they can just ask someone who understands the needs, without the need for a more complex set of bug report attributes.

wool_gather 7y ago
I agree with your overall point I think, but I find that people in general just work better when they have some context for their task and its priority/relevance. Absent that, they sometimes -- consciously or not -- decide "this is stupid" and either rush to just check it off or slow-walk it by allowing themselves to be distracted by other things.

hu3 7y ago

Developer knowledge of business needs is rarely on the low end of the spectrum. For example in the teams I lead I make sure developers participate on PO + stakeholder meetings as observers. This way when devs fix something or develop a new feature they know first-hand what the business expects. A nice bonus is that the team often gets personal praises from our clients.