Cookies on

This web site uses some strictly nesessary cookies to make this web site work.

We would also like to set additional cookies to understand how you use, remember your settings and improve our services.

Defect Tracking - Picking Priorities

I have been setting up a defect tracking system called FogBugz today. As part of the process I had to set up the Priorities list. Having explained to people, once too often, that "The font colour of the site copyright message is not a priority one defect!" I thought I should come up with a description of what each priority actually means.

Now rather strangely FogBugz requires you have exactly seven priorities. Not six, not eight but seven. So I came up with the following list trying to emphasize the height of Priority 1. Note how I have called one "Normal". Do you think people will guess which one they should pick?

Defect Tracking Priorities
Number Name Reasons for Selecting Expected Response
1 Show Stopper The company cannot continue its main line of business until this defect is resolved. A significant financial loss is occurring. By selecting this priority youare requesting that support staff and developers put in overtime (not get any sleep, get divorced, etc) to resolve the defect.
2 High Either the customer or client is suffering loss as a result of the defect, however the loss is low enough to be bared for a few days. A release of the product will be generated specifically for this defect, however staff overtime will not be used.
3 Normal Defects that are a priority to the business but are not currently causing loss. Defects of this priority will be resolved in the next release and, if necessary, the release will be held up to include them.
4 Low This is where you should stick font change requests and defects that are unlikely to be noticed by a user of the system. The development team will attempt to resolve these defects in thecoming release, however if the schedule slips the release will not be held up.
5 Fix in next release For feature requests and large changes to the system that will need estimating and planning. A project manager will look at these and cost them for inclusion in a future release.
6 Don't fix Defects raised for information purposes only. No action will be taken on these.
7 Undecided Use this while seeking advice on which of the above to select. No action will be taken on these.

So what do you think? What priorities do you use for your defect tracking and why?


Re: Defect Tracking - Picking Priorities

That's kind of lame that this Fogbuzz allows exactly 7 priorities !

We use Gemini for our issue tracking. It is .Net based and we are able to customize it as we please.

In terms of priorities, keep it very simple. We have only four.
Show Stopper, High, Medium, Low.

I think that some of the one you have listed, like "Don't Fix", and "Undecided" are more appropriate "Status" values, rather than "Priority" values.

Comment from Shiva at Tuesday, 06 March 2007 09:52PM (GMT+00)

Sorry, this post is no longer accepting comments.