What we can do to make it easier for vendors to ship the next version of our software is making it clear what needs to be done before a release. That would mean: “Here’s a list with what the next release will look like, if you want to make it happen earlier, help us hacking” This could be as easy as recording this in bugzilla, marking it as “showstopper” or “required for x.y.z” and then make the query showing those entries easily accessible through, for example, a direct link.

I quickly realized that my team wasn’t prioritizing for itself – but was prioritizing bugs around management and other perceptions of how other people in the organization would *force* us to prioritize bugs. So in essence my development team wanted to make pre-emptive political choices when it came to bug fixing. Any advice for making this process less frustrating?

Responses review the standard way to prioritise bug fixes.

1. How to Decide What Bugs to Fix When, Part 1; and
2. How to Decide What Bugs to Fix When, Part 2.

He argues that:

Here is the golden rule of organizing bugs: fix bugs in the order most likely to result in success. Sounds obvious, right? Wrong. I’d bet that more than half of the buggy and unreliable software you’ve ever used was that way not because the developers didn’t have time to make it better; they simply fixed the wrong bugs. Wanting to fix the right bugs and knowing how to do it are two different things.

He describes four approaches to bug prioritising:

1. triage: sorting bugs into Must Fix, Might Fix and Won’t Fix;
2. triage with severity: adding severities of data loss, functionality difficult, or annoyance;
3. setting exit criteria: defining the minimum set of “must do” goals; and
4. early planning based on previous experience.