4 ms·
> 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
by 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.