How to handle bugs in the Sprint Backlog

During the Scrum trainings I give at Valtech Training, I often get asked how the bugs should be estimated. Sometimes, the question is about various architecture tasks or GUI updates.

First, it should be clear that all these are technical debts. Yes, they are very common. Yes, it might be impossible to completely get rid of them. But still, they are evidence that the work done in previous iterations was less than optimal. It is therefore appropriate to address them during the retrospectives. Ask the usual questions: “we received 20 bugs during the last iteration. What can we do to reduce that number in the future?”

Because these items are technical debts, they should not be estimated in story points. We want to make clear that there is no functional gain from fixing bugs or refactoring the architecture. This means that, in practice, the number of story points that can be handled during an iteration might be less than before because of the time spent on bug-fixing. This is a good thing (of sorts): it makes clear that things are going slower, precisely because of our sub-optimal work in the previous iteration.
So, I recommend not estimating them in story points. I also recommend dimensioning the iteration with the same number of points as before: generally, with the developers increasing their velocity, it might be possible to work on the technical debts while still maintaining the same velocity. If that is blatantly impossible, then take a drastic measure such as halving the number of points for the coming iteration. You want to make it clear that things are not going well.

Although the technical debts should not be visible in the Product Backlog, it is probably worth having them in the Sprint Backlog.

From the point of view of tracking, this is not strictly necessary: the team members should handle bugs as soon as they hear about them. However, I have found that they are more comfortable when they can relate to an actual task in the Sprint Backlog. The simple fact of moving a sticky note on the wall make them more confident during the Standup meeting.
For some tasks, it is also useful to have sticky notes as a reminder that they must be dealt with. This is particularly the case of architecture refactoring.

At any rate, these tasks should definitely be estimated in ideal engineering hours. Usually, this is not a problem for architecture tasks (“we feel we’ll need 16 hours to update this package”). For other bugs, the best is to make an educated guess using yesterday’s weather (“we’ve spent 40 hours last iteration on bugs, but there are more users this time, so they might catch more of them. Let’s say 50 hours.”).

It is possible that bugs will reveal to be much more complex than expected. In this case, simply tell the Product Owner as soon as you are aware the iteration goals cannot be met, and see if some features can be dropped.

To sum up:

• if technical debts are more or less recurrent, just deal with them in the Sprint Backlog, and do not change your velocity (much)
• if the technical debts appear very complex to fix, negotiate with the Product Owner before the start of the iteration (“how would you feel if we spent the next entire Sprint fixing bugs? what about half of the Sprint?”), or during the iteration (“we thought at the beginning of the sprint that there would be a certain amount of bugs, but evidently, there are much more than that. What task can we drop?”)
• in all cases, always reflect on how to improve the situation.

Update (05/01/08): a translation in French of this article has been posted to the Valtech France Blog.