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." It sometimes depends on the teams precise circumstances but more importantly 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, there are three basic responses 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 the work being done in the current sprint.
In other words, it is a serious bug that must be fixed as quickly as possible. In this case, the sprint must be aborted and the team released to work immediately on the bug. Once the bug has been fixed, a new sprint is planned and started in the usual way.
This should be a rare occurrence. If every iteration has to be aborted for this reason, then more remedial action is required; a sprint dedicated to reviewing and improving the quality of the areas where 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 it is committed to be fixed by the team as part of the next sprint, in just the same way as other high value items on the backlog.
- The value to the business of fixing the bug is enough that the business want the bug fixed by the end of the current
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 these 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.
How does this compare with addressing bugs in other agile approaches?
In a Kanban based approach, there is less difficulty addressing bugs because there are no fixed length iterations, just limits to how much work can be in progress at any point in time. This means an important bug can be placed on the back log as the next item to work on, and it will be worked on as soon as an item currently in progress gets completed. For critically important bugs, the Kanban board would be largely frozen while the team addressed the critical bug as an exception to the usual process, again as in Scrum, assuming critical bugs are rare.
FDD runs multiple, variable length development iterations concurrently. Each iteration is led by a Chief Programmer . On an FDD project, I would typically maintain a separate prioritised list of bugs and assign them to Chief Programmers in the same way features are. It becomes the Chief Programmers responsibility to schedule the bug fixes into an iteration appropriately based on relative priorities to new features and other dependencies; the development manager raising the priority of bug fixes if too few are being addressed. Again, critical bugs are addressed immediately as an exceptional, out of process, activity.
one of my old software managers, 1990
FDD combines key advantages of other agile approaches with model-centric techniques and
fluid team organisation. This means that FDD easily scales to much larger teams and projects than generally recommended
for other agile approaches. FDD is also characterised by an emphasis on quality throughout the process, and timely,
accurate, meaningful status reporting and progress tracking for all levels of leadership.
Domain-Driven Design comes as a bit of a surprise to those who have been taught
that agile software development and especially eXtreme Programming do away with the need for analysis and design
techniques like object modeling and notations like the Unified Modeling
Language (UML). It is actually very obvious that any software team working in a .Net language, Java, Objective-C,
C++ or any of the object-oriented dynamic languages such as Python or Ruby has an object model at the heart of their
The premise behind eXtreme Programming is that the cost of making changes to software does not need to grow
exponentially more expensive throughout a project or product development life-cycle. That the cost of change does
increase exponentially over-time is attributed to unnecessary complexity added early in the project product life-cycle;
complexity that provides the flexibility to address all the changes that might be asked for in the future.