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
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:
- Regressions: When a subsequent development broke a formerly functional part of the code.
- 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
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
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.
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.