At a lot of organisations that I've worked there is a tendency to prioritise bugs by a priority bucket.

We might therefore have priority buckets 1-4 where the bucket number indicates how important the bug is to fix and then any buckets ranked below 4 would not be fixed but would be logged anyway.

From what I've noticed this isn't a particularly effective way of managing bugs.

To start with there tend to be a lot of discussions around what the priority of each bug should be where a QA will argue that it should be a higher priority while a developer disagrees.

I'm not convinced that we actually get any value out of these discussions.

Another thing that I've noticed recently is that developers are much less motivated to fix bugs if they've been put in Bucket 4 rather than one of the higher priority buckets.

I think a better way to solve this problem is just to store whether or not we're going to fix the bug before the next release or not. We can then list them in the order that they should be fixed as well.

It's a much simpler binary categorisation and there's no stigma attached to picking up a 'low priority' bug because each bug picked up is just the next one on the list.

We did this on one project I worked on and it was interesting to notice the number of bugs the client was completely disinterested in fixing before the next release because they just weren't that important.

I'm not convinced the same thing would have happened if we'd categorised by bucket.

The added benefit of this approach is that we can avoid discussions where we identify how many bugs of each category have been identified each iteration.

In some organisations the ability to detect higher priority bugs is an indication of the quality of QA work but I don't believe this is a useful metric to track.

From http://www.markhneedham.com/blog/2010/12/12/bugs-prioritising-by-bucket/