Priority call

Defect found, fire up the bug tracker!

• Summary: Nice and easy, brief description of the problem. Just enough detail to identify which defect this is.
• Description: All the (relevant) details. Succinctly stated, neatly organised, enough to bring anyone up to speed with the issue.
• Priority: ???

And that's where it can get tricky. From whose perspective do you judge the priority? Here are a few options:

1. End user: how will this impact the actual users of the system?
2. Client perspective: will the client sign off the product with this bug unresolved?
3. Specification: in terms of violating the system requirements, how serious is this problem?
4. Testing impact: how important is it to get this fixed in order that testing can be completed?
5. Complexity: how complicated will this be for a developer to fix?

There are likely many more depending on the particular testing circumstance, and each of these may result in a different priority. For example, if you are looking at the homepage of a website:

• 404 error: a straightforward one, likely a blocker from all perspectives.
• spelling mistake in headline: from the development and testing viewpoint this is minor, but as the first thing a user will see this could be very severe (it could well cause a user to bounce from the site)
• link to a subpage not working (but page exists): high priority to the client if this is the primary route, but will depend on the importance of the page (which will be subjective).  
• page layout not matching designs: very severe from the point of view of the spec, but if the layout is not clearly broken this may be lower level from the perspective of the user/client
• module on the page not loading: if it is not obvious the module should be there, and it doesn't deliver crucial functionality, this might be low priority for the user, but due to the integration aspect this might be a time-consuming fix for the developer which they would want to investigate sooner.

So how to resolve these conflicting points of view? One question we have to ask ourselves: what is the reason for assigning priorities in the first place? In my experience the primary usage of this field is to determine the order in which issues will be worked on by the dev team, so we need to approach the setting of this field with that in mind. Following on from the suggestion I gave in Looking forward, move to the end of the process - if the product was delivered with defects at that level still in place, how would that affect the quality? So, corresponding to the standard priority options in Jira:

Blocker: something will appear visibly broken to the user
Critical: functionality may be reduced compared to the original spec but this may not be obvious to the user
Major: some areas may not work optimally but all functions can be achieved
Minor: users might experience some inconvenience but most functions work as expected
Trivial: some users may spot an issue but all functions will work as expected

[Side note: part of the issue with priorities are the language used; for example I can easily imagine a Trivial Blocker, i.e. simple to fix but devastating in effect. Here I've gone with what I think is the standard interpretation of these values, being a sliding scale from highest to lowest priority]

One reason I like this approach is that it is independent of the current status of the project. I've been through some hellish projects where defect priorities were changed daily according to the current project progress or opinion of the person currently reading the defect (including instances of the developer changing the priority without any discussion) - this can work if all defects are updated on a daily basis, but is extremely time consuming and can easily lead to confusion.

There can never be a hard-and-fast rule here as there will always be edge cases that need to be given special treatment; the main aim should be to easily provide a plan of attack for the majority of cases, so that product can be delivered as efficiently as possible. And that's a priority no-one will argue with.