I think everyone knows the situation. A bug is found by someone in your company. Not a user, but a developer, salesperson, or any other person. When do you solve it? Solving a bug, that is not found by a user compared to functionality that can earn the company money, is an easy comparison. The new functionality will almost always win. But then…. when will you solve that bug?
Many Agile methods prioritize based on value. What adds the most value to the company? Fixing a bug itself doesn’t add value at that moment unless it is found by users or customers. When it is found by users or customers, you have the risk of losing them. Or at least they will complain. But if the bug is not found by a user or a customer, solving the bug doesn’t add value.
This conflicts with the general approach for reaching a product of good quality. If you want to have a good product, your goal is often to solve bugs as soon as possible. That means having a quality process in place that tries to avoid bugs being found by users or customers. So a conflict arises. Looking at the value, a bug can wait. Looking at the quality, you need to solve it now.
Looking different at bugs
The most important thing in a company is that solving bugs is seen as something that does at value. So, how do you do that? Look at fixing bugs more like you would look at insurance. When you insure your house against fire, that doesn’t add value now. Now it is just a cost. But when the fire occurs, you are glad you did it.
Or look at them the same as other measures you take to prevent for example a good bicycle lock. You might buy an expensive one for a new bike and at that moment that does not add any value. Still, you do not want to find out you needed it after your bike is stolen.
Solving bugs is about reducing risk and that is what adds value. Just like any other prevention measure. And just like any other prevention measure, you see how much it is worth by looking at three things: how high is the risk of this happening, how much will it cost if it happens, and how much cost to prevent? Prevention in this case is solving the bug.
Good prioritization
One way of determining the value is by using the bug ranking: Blocking, Critical, Major, and Minor. Or any other order that looks like that. The thing is, when bugs are found by users and customers, you prioritize often on number of users affected and the costs of the damage caused by the bug. For bugs not found by users and customers, replace those two with the risk of the bug happening and the costs of the damage it will cause when it happens. This way you can prioritize bugs found in production and bugs not found in production. And plan it accordingly in your Agile process.