Improving Bug Triage with User Pain (2008)

A former employer implemented this in the 2009/2010 time frame. We were at that point an old software company with mature products, lots of process, custom internal tools, and very separate product management, support, development, and QA. The various category ratings had some data input, but were done by hand, so a person was always directly involved. We used user pain for maybe a year before the company adopted scrum and began migrating to entirely new tools/process; user pain was not retained.

My recollections are that we found lots of room for disagreement over whether something was a particular number on one of the scales, and depending on the bug and personalities involved these arguments could last a while. It was straightforward to game the scale to make particular issues show up with a high or low pain, regardless of how many customers actually reported it (if any - unfortunately user pain does not include a 4th 'imagination' rating).

One development manager told me he really liked User Pain because it was straightforward to make defects reflect a low pain number such that they could just be ignored.

It was a short experience, but I don't think I would want to implement user pain again unless the category ratings were entirely data-driven and automated. I don't think this method is useful if you leave the ratings up to people.

To quote Jerry Weinberg: "Quality is value to some person"[1]. Any reasonably complex system is going to have different users with differing quality requirements: administrators, tactical operators, strategic operators, sophisticated operators, naïve operators... Whose pain are we accounting for?

[1] https://en.m.wikiquote.org/wiki/Gerald_Weinberg