Sometimes, a problem in a software development process or in the ways of working can cause some types of issues or bugs to occur continuously. If they each on their own have low impact they might be given a low priority, but over time they might accumulate to become a problematic amount. Therefore, it can be worth to also investigating the lower impact issues to understand why they occurred.
An example of a low-impact issue comes from a project I was working on; it was found during the development of an automated check:
Bug: A button becomes partially hidden at the bottom of a web-page when a certain number of entries is entered into a list that is displayed at the top of the page.
The button could still be pressed so the impact of the bug was low (which in my opinion was correct) but I started to think about why the issue had occurred at all. It could, and should, have been caught before the story or feature was considered “done”. It was obvious too see if you filled the box with the amount of items we expect our end-users to have. Instead, it was caught after delivery which was expensive because of the following reasons:
However, it occurred to me that if our process or way of working continuously creates these types of issues it might become significantly more expensive to fix in the future. An customer might not have a problem to use a work-around in one or two cases, but if there is a need for this everywhere in the workflow then it might become a major problem making a bad impression on the customer. In a worst-case scenario this may lead to the customer looking for alternatives to our software.
I asked myself if the root cause for the issue occurrence could be one, or all, of the following issues with the process or our way of working:
If any of the above is a root cause, there is a risk of ending up with a number of low impact issues (if not addressed because of the priority) that eventually makes the product polish crumble, killing the customer experience with a thousand cuts.
At the time of writing, I found for this particular example, the root causes were a mix of everything above and it was valuable to have done the digging.
Hopefully these actions will help prevent future accumulation of similar kinds of issues because it most certainly would have continued if the flaws in our process would not have been addressed.
It is always a good idea to ask why an issue occur, even if it has low impact. Identifying and correcting an underlying problem can save a project from an accumulation of low impact issues that might over time become a major problem. If these issues are ignored, due to low priority, the underlying problem with the process or way of working might not be understood before becoming expensive to solve. Make sure not to neglect the lower impact issues, they just might help you uncover a high impact process issue before it creates a problematic number of issues.