The defect decision matrix

Those days I was on twitter and found a very interesting post made by Tomas Rybing (@TheAgileist). In this post Tomas describe a daily meeting they run to do a bug triage. In one of my projects we did something similar that we call the defect decision matrix.

The defect decision matrix is nothing more than an agreement between the Product Owner and the QA Lead (or someone from the dev team if you don’t have a QA lead). Both sit together to define how defects should be address accordingly to its priority (defined by the PO) and impact (defined by QA lead). Very similar as described by Tomas. Its look something like this:

We have priorities, defined by the PO, as the columns, each team may have it own definition, for instance:

• 1: Clients will feel like :~((((( OR High priority, main feature affected
• 2: Clients will feel like :O :S OR Medium priority
• 3: Clients will feel like :| :/ OR Low priority, clients can wait (low usage feature, not on usual path)

Rows are impacts defined by the QA, each team may have it own definition, for instance:

• 1: Crash:> 80% cannot print on happy path OR Major issue on happy path
• 2: Intermittent Crash Between 20% & 80% cannot print OR Major issue on alternative path OR Typos
• 3: Minor issue: < 20% cannot print OR Bad UX OR cosmetics

Did you liked the idea? Comment & share!