Fixing an error found after a feature was implemented, like any other job developers undertake, has a priority. This priority will tell developers how important is a bug compared to other tasks, including adding new features and updating existing ones. When thinking about a project from a perspective of business, the line between errors and functions is blurred. Why? Let’s look at an example: users want a new feature in the system. It will increase their satisfaction with it and maybe more of them will remain active users if we add it. At the same time we arrived at this realization, we discovered a bug that prevents users from resetting passwords to their account. Let’s also assume we can’t do both things at the same time, add the valuable function and fix the bug due to the limited time of developers. What should we do?
If there aren’t many complains about resetting passwords, I say we should add the function first. Of course, everyone wants a bulletproof system without any errors. But a system like this potentially costs an infinite amount of money as no one ever created such a system.
This is why I urge software houses that use agile methods to connect their product backlog with their "errors backlog" (and promote this approach to customers). Only then will they know what to do next and plan their week appropriately. In scrum, for instance, there is a product owner who plans tasks with developers. Let them use two lists if they really want: one for features and another one for bugs but in the end at least, the sprint backlog should be a combination of the two. Otherwise, it won’t be clear what to do. Not all bugs take few hours of work to fix, they aren’t irrelevant compared to the rest of work and are sometimes discovered months later.