Bugs create a special atmosphere. They often cause a lot of unrest or outright panic. But does it have to be that way?

Nearly every developer out there has come across the following scenario: The development team is working on the sprint backlog when suddenly the users report an incident. The marketing manager comes in and puts pressure on the development team or their product owner to urgently fix the bug. The team feels guilty so some of the developers stop working on whatever they've been doing and focus on fixing the bug. They eventually succeed, and now the testers shift their focus as well to verify the fix as soon as possible, so the developers can release a hotfix. The hotfix is deployed, sprint passes by, and the originally planned sprint backlog is only half-done. Everyone is stressed out.

A similar situation is often created by a product owner: He finds a defect in functionality, created two sprints ago, but demands an immediate repair.

Is this all really necessary? Sure, some issues have a great impact on the product or service, and then this approach might be justifiable, but rather often this kind of urgent defect whacking is a process that is more emotional than rational. So how to treat bugs systematically?

What are bugs and bug fixes?

A defect, incident, or simply a “bug” is effectively any deviation of the existing product from its backlog. Any behavior that is different from the one agreed upon between the dev team and a product owner can be called a bug. Bugs aren’t only defects in the conventional meaning (e.g., crashes or computational errors); a technically correct behavior in conflict with a boundary set by a user story can also be considered a defect.

Some bugs are related to the product increment being implemented in the current sprint. Other bugs are found retrospectively: They are related to the user stories developed in past sprints. These fall into two categories:

1. Regressions: When a subsequent development broke a formerly functional part of the code.
2. Overlooked bugs: They were always there, but no one had noticed.

Conversely, a bug fix is something that adds value to the current product by lowering the above-mentioned deviation. It requires a certain amount of effort and it raises the value of the present product. At the end of the day, a bug is just another unit of work, and we can evaluate its cost/benefit ratio. It is the same as any other backlog item.

A bit of psychology

Scrum teams and stakeholders tend to approach both defect categories differently. They also treat them differently than the “regular” backlog items.

In my experience, there are two important psychological factors influencing the irrational treatment of defects.

First of all, there's often a feeling of guilt when a developer is confronted with a bug. The natural response of most people is to try to fix the error as soon as possible so that they feel they are doing a good job. Developers naturally want to get rid of such debts.

Another factor is how people perceive gains and losses. People are evolutionarily averse to losses because the ability to obtain and preserve resources has always been key to survival. There have been studies concluding that on average, people perceive a loss four times as intensely compared to a gain of the same objective value: If you lose 5 dollars, it is four times as painful compared to the gratification of finding 5 dollars lying on the ground. You need to find 20 dollars to have a comparable intensity of feeling as when you lose the mentioned 5. The bug/defect/incident is perceived as a loss for the team's product, especially if it's a regression. A small bug can therefore be perceived as much more important than a newly delivered valuable feature.

Don't get me wrong—I am not saying that bugs are not worth fixing or that they don't require any attention. That is obviously not true. One of the key principles of scrum is to deliver a functional, potentially releasable product increment in every sprint. That means that a high development quality is fundamental and teams should always aim at developing a debt-free product. Nonetheless, bugs will always have to be dealt with.

Bugs caused by newly added code

When working on a sprint backlog, the team needs to set up a system to validate the increment they’ve just developed. The goal is to make sure that at the end of the sprint, a feature is free of debt, and can be potentially released. Our experience shows that during a sprint backlog development, the team should focus on removing any bugs related to the newly developed features as quickly as possible in order to keep the feedback/verification loop as short as possible. This approach maximizes the probability that a newly developed user story is done by the end of the sprint and that it is potentially releasable.

Sometimes there are just too many bugs and it becomes clear that not everything planned in the sprint backlog can be realistically achieved. The daily scrum is the opportunity to point this out. The development team and the product owner together can then concentrate their efforts on a smaller amount of in-progress user stories (and related bugs). It is always better to make one user story done by the end of the sprint than to have ten stories halfway finished. Of course all bugs should be recorded transparently in the backlog.

Remember, a user story is an explanation of the user's need that the product tackles, together with a general boundary within which the developed solution must lie. A common pitfall is that the product owner decides on the exact way for developing a (e.g., defines the exact UI or technical workflow) and insists on it, even though it is just her personal preference. This approach not only reduces the development team's options to come up with the most effective solution but also inevitably increases the probability of a deviation, thus increasing the number of bugs as well.

Regressions and bugs related to past development

I think it's important to treat bugs (or rather their fixes) introduced before the current sprint as regular backlog items and prioritize them accordingly. Whenever an incident or regression is discovered, it must go into the backlog and decisions need to be made: What will be the benefit of that particular bug fix compared to other backlog items we can work on? Has the bug been introduced just now or have the users already lived with it for some time and we just did not know it? Do we know the root cause and are we able to estimate the cost needed to fix it? If not, how much effort is worth putting into that particular bug fix, so that the cost/benefit ratio is still on par with other items on the top of the backlog?

By following this approach, other backlog items will often be prioritized over the bug fix, which is perfectly fine. Or the impact of the bug might be so negligible that it's not worth keeping it in the backlog at all. One of the main scrum principles is to always invest the team's capacity in stuff that has the best return on invested time/costs. When the complexity of a fix is unknown, we have good experience with putting a limit on the invested capacity. For instance, we said that at the present moment, this particular bug fix is worth investing 5 story points for us. If the developers managed to fix the issue, great. If not, it was abandoned and re-prioritized with this new knowledge. By doing this, we mitigated the situations when developers dwell on a single bug for weeks, not being able to fix it.

I think keeping a bug-log greatly hinders transparency, and it’s a sign that a product owner gives up on making decisions that really matter and refuses to admit the reality.

Final words

I believe all backlog items should be approached equally. A bug fix brings value in a similar way as a new functionality does. By keeping bug fixes and new features in one common backlog and constantly questioning their cost/benefit ratio, we can keep the team going forward, and ensure that critical bugs don't fall through.