I’m working on a project that is in the testing phase right now, so defects are on my mind.  As product managers, we often have the job of prioritizing defects.  Unfortunately, I often run into people who aren’t aware that there is a difference between defect priority and defect severity.  The article Arguing Apples and Oranges does a great job of explaining why this is a problem and the difference between the two.  I recommend it as a fun, quick, informative read.

I frequently see IT organization cringe at the notion of using the priority of defects to determine release readiness.  I’ve heard the statement “if you use priority,  it means you could hold up the entire release for a single typo”.  This is where trust between the business and IT comes in.  It must trust that the business to apply sound judgment in making the priority decision.  In most cases, a single typo should not hold up a release.  But, what if you misspell the company name on the home page?  Or, end up with an obscenity?  The “severity is king” attitude ends up with “it’s just cosmetic; it doesn’t matter”.  But, it does.

So how do you bridge the trust gap?  You quantify the priority.  Base it on ROI.  Sometimes the ROI is obvious:  this feature accounts for 25% of the value of the project.  If it doesn’t work, we lose 25% of our project ROI.  Other times, ROI takes a little more thought.  But, there should always be a sound reason for investing in code.  For example:

• Our business is based on our reputation.  We believe this defect will damage our reputation such that 1 out of x users will decrease their spend with us by an average of y%.   Let those with the most knowledge determine the variables, then do the math, and you’ll have a cost of not fixing the defect.
• A hard-to-use but functional interface will result in x% of employees choosing to leave their job, with a turnover cost of $y per employee.  Again, do the math.
• We anticipate that users experiencing 3 or more typos while performing their daily tasks will result in 2% of the users deciding the poor attention to quality means  the functionality will be equally as buggy, therefore they will refuse to adopt the application.
• We are reducing risk. We are fixing typos and easy-to-fix errors in the early days of testing, so we mitigate the risk of ending up with a death by 1000 paper cuts.  Remember, the 1000 cuts include the cuts (defects) you don’t know about before release.
• And, sometimes it is about employee satisfaction.  We choose to let a developer fix a defect because we know it is going to drive him crazy if he doesn’t. The money we invest to fix the bug is well worth it to keep his morale up and his standards high.  Be careful using logic like this, while you can and sometimes should make minor concession, you shouldn’t let anyone’s pet feature drive the decision making.

Prioritizing will always include a dash of art, but it shouldn’t be pure art.  The team should be able to understand and support the priorities.