Eventually, everyone who has done some basic Scrum training asks the question, “How do you handle the fixing of bugs? Where does this fit in the process?”
As usual the answer is, “It depends.” Sometimes, it depends on the teams precise circumstances but more often it depends on the number and severity of the bugs.
One of the guiding ideas in Scrum is to concentrate on delivering items of the highest business value as early as possible. The product owner ranks items on the product backlog in terms of value to the business, highest value items at the top. The development team take items off the top of the list to work on next.
When a bug is reported, a team has three basic responses available el to them depending on the value to the business of fixing the bug.
- A fix for the bug is of much more value to the business than work being done in the current sprint.In other words, the bug is so serious that the team must fix it as quickly as possible. In this case, the team aborts the current sprint, and works on the bug immediately. Obviously, it may not require everyone on the team to fix the bug. Those not involved can continue to work on the items from the original sprint while the bug is fixed. However, whatever effort is needed to fix the bug takes priority over other work. Once the bug is fixed, the team either re-plan and restart the sprint, or if very close to the end of the current sprint, they may choose to plan and start a new, slightly-longer-than-usual sprint instead.Interrupting or aborting sprints like this should be a rare occurrence. If every iteration has to be aborted for this reason, then the team need to take more remedial action; a sprint dedicated to reviewing and improving the quality of the areas where most of the bugs are being found, for example.
- The value to the business of fixing the bug is less than the work being done in the current sprint.In this case, the bug is entered as an item on the product backlog and prioritised alongside all the other items by the product owner in terms of value to the business. If it’s value is great enough, the team commit to fix it as part of the next sprint, in just the same way as other high value items on the backlog.If the value of fixing the bug is not great enough then it remains on the backlog until all higher value items have been delivered. The Product Owner needs to demonstrate good discipline and strong leadership skills here, and avoid the pressure to always prioritise the delivery of new features over that of fixing bugs. If the Product Owner allows to many unaddressed bugs to build up on the backlog, the team ‘s productivity and velocity will drop as they spend time working around the bugs in their code. The team’s productivity needs to be taken into account when evaluating the value to the business of fixing the bugs.
- The value to the business of fixing the bug is enough that the business want the bug fixed by the end of the current sprint.This third option is really a compromise. Ideally, this level of bug should be handled as either case 1 or case 2 above. However, it often takes a level of maturity in doing Scrum to constrain the business to the first two options. The compromise, is to dedicate a certain proportion of a team’s capacity during each sprint to bug fixing. If a team can generally complete about 30 story points worth of work in a sprint, then the team can agree with the product owner to reduce that to 25 or 26 to free up 4 or 5 story points worth of capacity to fix these kinds of bugs as they arrive. The exact proportion will depend on the frequency of this level of bug. How exactly the ‘bug fixing time’ is allocated during the sprint is for the team to organise, balancing the cost of context switching, the effort needed to fix a bug, and avoiding compromising the sprint commitment. Obviously, if the number of bugs of this sort arriving during a sprint exceed the spare capacity, the product owner is faced again with either aborting the sprint or adding the bugs to the backlog for consideration during the next sprint planning session. In contrast, if fewer bugs of this severity are reported during the sprint, the team should be able to pick up some more work from the backlog.The amount of overhead and complication that this compromised way of addressing bugs introduces is significant. If this approach is adopted, one of the goals I would have as a team is to gradually eradicate the need for it by identifying the sources and causes of bugs of this severity, and looking to introduce and adapt working practises that eliminate or at least severely reduce them.