The specification for the "Severity" and "Priority" in PS is not very clear, following are more explanation for the two fields and some example scenarios are listed:

Severity - Communicates the perceived impact of the issue. Severity often impacts the priority of a bug but there are cases where a high Severity bug may be lower Priority. Some general Severity value definitions:

 • Severity 1 - Bug causes system crash, data loss, major test blockage, high security risk, broken build, failed BVT/BAT/CIT or customers can’t use the feature. Whole product appears unstable. Inadvertent user action causes data loss. Inconsistencies are guaranteed to cause end-users to fail to perform the function and/or call product support.

• Severity 2 - Bug causes major functionality or for the product to appear poorly engineered. Product crashes in obscure cases. High customer or test impact. The feature is obviously inconsistent with other elements of the product. These inconsistencies are likely to cause end-user confusion, frustration and failure on key actions and common usage.

• Severity 3 - Bug causes minor functionality problems with a simple work around or has small customer or test impact. Customers annoyed by / aware of product inconsistencies. Product appears unprofessional. Inconsistencies that make Dynamics look arbitrary, unfinished, randomly different or of poor quality resulting in lower satisfaction with the product. Users will notice them and wonder why this is different, but they will likely NOT fail in key interaction.

• Severity 4 - Very minor problem such as misspelled words, incorrect tab order in UI, obscure feature broken, little or no test impact. Bug contains typos, unclear wording or error messages in low visibility fields. These inconsistencies in the product are NOT likely to be noticed by any user or are in areas that are rarely used.

Priority - This determines how important it is to fix the issue indicates the order in which bugs should be addressed:

• Pri 1 - Must Fix – this milestone.

            Required for key scenarios, customer feedback, impact to other scenarios, hotfixes delivered by SE, etc.

• Pri 2 - Must Fix – in next milestone / before RTM.

            Doesn’t require tap/beta feedback, can’t be completed this milestone, future work dramatically impacts design around this bug.

• Pri 3- Should fix, but could ship without