<story><title>Don’t Confuse a Bug’s Priority with Its Severity</title><url>https://www.bluelabellabs.com/blog/dont-confuse-a-bugs-priority-with-its-severity/</url></story><parent_chain><item><author>whack</author><text>&amp;gt; &lt;i&gt;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 release for, while P2s (Medium,Low) represent pretty much anything that will only be fixed when our development team has cleared all P0 and P1 bugs&lt;/i&gt;&lt;p&gt;&amp;gt; &lt;i&gt;It’s important to note that a bug’s priority shouldn’t be confused with its severity, which exists as an entirely different dimension... ‘Severity’ to represent a (somewhat) objective assessment of a bug’s impact to the functionality of the system. From Critical representing major crashes or hangs, to Minor functional issues or purely Cosmetic blemishes. While a QA engineer will classify a bug’s Severity at creation time, it’s the PM who assigns the Priority at the time of triage based on their knowledge of the client’s business and product requirements&lt;/i&gt;&lt;p&gt;I don&amp;#x27;t see the benefit in having severity and priority as 2 distinct dimensions. Given a specific priority, what additional benefit do you get from having a severity label as well? Based on the author&amp;#x27;s description, I can&amp;#x27;t think of any.&lt;p&gt;If the goal is to better communicate what &amp;quot;type&amp;quot; of bug it is, using an enum classification (eg, cosmetic vs crash vs data-corruption) would be more appropriate than a numeric scale.</text></item></parent_chain><comment><author>nolok</author><text>Because as the quote said, it depends on the client requirement.&lt;p&gt;&amp;quot;if you click anywhere in the left half of the screen during the 5th screen all the settings get deleted&amp;quot; might be a very severe&amp;#x2F;critical bug, but if the client says &amp;quot;thats fine for me don&amp;#x27;t worry, but can you fix the wrong color on screen one where the logo is purple instead of fuschia that&amp;#x27;s not acceptable for my needs&amp;quot; then this one has a higher priority, even though it&amp;#x27;s much less severe.&lt;p&gt;Your job is not to build the perfect&amp;#x2F;best product, it&amp;#x27;s to build the one your client want and is willing to pay money for.&lt;p&gt;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.</text></comment>
<story><title>Don’t Confuse a Bug’s Priority with Its Severity</title><url>https://www.bluelabellabs.com/blog/dont-confuse-a-bugs-priority-with-its-severity/</url></story><parent_chain><item><author>whack</author><text>&amp;gt; &lt;i&gt;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 release for, while P2s (Medium,Low) represent pretty much anything that will only be fixed when our development team has cleared all P0 and P1 bugs&lt;/i&gt;&lt;p&gt;&amp;gt; &lt;i&gt;It’s important to note that a bug’s priority shouldn’t be confused with its severity, which exists as an entirely different dimension... ‘Severity’ to represent a (somewhat) objective assessment of a bug’s impact to the functionality of the system. From Critical representing major crashes or hangs, to Minor functional issues or purely Cosmetic blemishes. While a QA engineer will classify a bug’s Severity at creation time, it’s the PM who assigns the Priority at the time of triage based on their knowledge of the client’s business and product requirements&lt;/i&gt;&lt;p&gt;I don&amp;#x27;t see the benefit in having severity and priority as 2 distinct dimensions. Given a specific priority, what additional benefit do you get from having a severity label as well? Based on the author&amp;#x27;s description, I can&amp;#x27;t think of any.&lt;p&gt;If the goal is to better communicate what &amp;quot;type&amp;quot; of bug it is, using an enum classification (eg, cosmetic vs crash vs data-corruption) would be more appropriate than a numeric scale.</text></item></parent_chain><comment><author>alkonaut</author><text>The two values are good to separate if they come from different people&amp;#x2F;groups.&lt;p&gt;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 &lt;i&gt;severity&lt;/i&gt;.&lt;p&gt;Some completely different person can come along and give this a high &lt;i&gt;priority&lt;/i&gt; 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&amp;#x27;s a &lt;i&gt;priority&lt;/i&gt; to fix it.&lt;p&gt;A second reason might be due to ROI (easier severe bugs are better to prioritize than difficult bugs of the same severity).</text></comment>