Main menu

Category Archives: Scrum

How should bugs in agile projects be handled? More and more teams, which are going the agile way, are asking me how to deal with bugs in the future. The first time I did not understand the question. The background of the question is the same every time: When teams are starting with an agile process (e.g. doing a scrum crash-course) the scrum coaches often state that the team will not produce bugs going the agile way and the code quality will skyscrape. But when hitting reality again most teams will realize, that the bugs are utterly disinterested in that kind of theory and will still popup regularly.

But how should we deal with bugs, when we put our complete attention to the business value? It is ambiguous and hard to evaluate what the business value of a bug fix is.

The business value fixing a bug is equivalent to the impact of this bug on the business. That also implies that a bug having no impact on the business has likely no value to be fixed. But I’ve seen bug reports all over where more than 50% of the QA findings have filed bugs which had no real impact. Only a strong business decision instance can then prevent the project and development from being trapped and jeopardized by QA (I would even consider such bug reports partly as hidden feature requests of individuals). My experience is that an agile team has to put less effort in debugging code and has to fix lesser bugs than teams developing in a traditional way. If you do pair programming some of the bugs are discovered during implementation before the code is in production. As usual a good test coverage helps to find and fix bugs early and prevent them from popping up again. But this doesn’t mean that there won’t be any bugs anymore and one has to think about how to deal with bugs in agile projects. Bugs and software tend to stick tightly together and we experience them in our day2day scrum.

When a bug appears during an iteration and the bug is related to the feature which is currently under development. Then the bug should be fixed immediately. Otherwise the feature couldn’t be moved to the one compartment at the end of the iteration. In this case the bugfix is simply part of an existing task and related to the feature under development. Proven standards like test driven development have to back agile development.

Dealing with a bug which relates to a feature that was implemented several iterations ago is a bit more difficult. It depends on:

the complexity of the bug

the life-cycle of the project/product

A really simple bug, with a well-known scope, should be fixed in the running iteration but not by the committed resources (wildcard/joker). Is the bug far more complicated and the estimation to fix the bug is uncertain then the bugfix tasks should be planned and prioritized for the next iteration (depends on the prioritization), similar to a new feature.

Bugs, which occur in a running project or product and which have been reported by the customer tend to have a very high priority most of the time. These kind of complex bugs often cannot be handled in one of the following iterations and should be fixed immediately. Now the team or rather the product owner is in a catch-22 situation. On the one side, the product owner wants progress on new features but on the other side he wants to satisfy the customer by fixing the bug.

To deal with this problem I see 2 pragmatic options:

Bigger teams: A dedicated support team could be established. This team is exclusively responsible to current engineering and operations: Fixing bugs while the development team concentrates on implementing new features. This is one solution, but most organizations are having several reasons not to split teams into two groups.

In smaller teams the maintenance for the system is timeboxed. This timebox is used to resolve bugs or to maintain the system, e.g. cleanup jobs. This is a well-defined amount of time for each team member. The rest of the time is spent to implement new features. Currently we have 2 week iterations and each team-member has 2 days for maintenance. On top of that we have established a joker role. The joker has an additional day for unforeseen adhoc issues. The joker role rotates each iteration and each team member will become the joker from time to time.

I see that the Joker role also greatly increases the overall comprehension and awareness of the product/service the team works on. In general new bugs have a high priority (defined by the product owner) and as soon as a team member has finished a task, he snaps and fixes the bug. Each team member will do this as long as his maintenance timebox has not been consumed. All other bugs are moved to the next iteration (again defined by the product owner). The balance between maintenance timebox and feature progress has to be figured out individually depending on the priority of either maintenance or progress.

The split of roles, the best way to handle the wildcard/joker and the maintenance challenge all depend very much on the team. I believe that not all teams are capable to run a successful scrum and not all team members are prepared to run.