... as a team develops the product, issues are invariably detected. The usual tendency is to write issue reports and put them on an issue list, where they will be fixed at the appropriate time. But this leads to several problems that ultimately cause the velocity of the team to bog down.
✥ ✥ ✥
Velocity is limited because a team spends time dealing with too many issues.
It is natural to want to keep a list of issues, because working on issues is disruptive, doesn't seem to add value and for most developers no fun to work on.
The Scrum Team has defined their Sprint Goal and are focusing on achieving it. Issues that are reported are put on an issue list because the developers are busy with other tasks, and shouldn’t be interrupted. Issues that arrive might be considered low priority, and it’s nice to have a place to put them. If others (e.g. testers, users) find issues, issue reports and lists give them a convenient way of logging the issues. But it's easy for developers to leave them on the issue report list. (Maybe they hope that if they leave them there long enough, they will go away.). Such a list introduces waste and inconvenience to users.. Each issue has to be handled at least twice, once when it arrives, and later when it is fixed. Issue lists are generally prioritized, but how do their priorities match against the priorities of development items? Keeping separate lists causes this question to be revisited constantly. This creates work and causes context switching for the developers. The longer an issue sits before it is fixed, the greater chance there is of losing information about the bug, how to reproduce it, and how to fix it. If issues are allowed to sit on an issue list, further development might even depend on the bugs, making them that much more difficult to fix.
Written issue reports are designed to capture the problem, but they often miss important information, especially about how to reproduce the issue. The original finder of the issue may forget, or worse, no longer be available. And good issue reports take time and effort to write. Issue lists tend to grow. If they are allowed to get large, it virtually ensures that the lowest priority issues will never get fixed. Issue lists usually contain user-visible issues. This creates the possibility that another user finds the issue. If the user writes an issue report, you have duplicates, and managing duplicate issues is simply messy. And a user who finds a known issue is needlessly inconvenienced.
The Sprint is planned with Product Increment(s) that create value for stakeholders. Adding new features increases revenue, but fixing issues does not apparently increase revenue. So there is pressure to work on new features rather than fixing issues. If the team has a fuzzy Definition of Done, work might be considered Done, with some pieces deferred until later. Likewise, if the team's commitment to Done is weak, the same thing will happen. The work not done yet is basically an issue that is deferred.
New development is more fun than fixing issues. Therefore, there is a natural tendency to park issues in a list of things to do when all the fun stuff is done.
In short, to defer issue fixing is to borrow against your future velocity. This puts the team in debt to the product in that the team owes the product work. We call this technical debt. And it gains interest over time!
Fix all issues in less than a day. Aim to have a completely clean product at the end of every day.
This is simply practicing good housekeeping. If you find a cockroach in your house, you kill it right away.
In order to make this work, avoid the temptation to keep a issue list. You already have a list of work to do, the Sprint Backlog. As issues are identified, they are either fixed immediately or go on the Sprint Backlog to be fixed later in the day or the very next day. This allows developers to complete their current task without interruption, if necessary. Naturally, if it's an issue you find, fix it now, while it is fresh in your mind.
✥ ✥ ✥
Daily attentiveness to progress helps the team to learn how to produce a predictable Regular Product Increment.
For the sake of visibility, it's a good idea to put the bug on the Sprint Backlog or at least one of the other information radiators like the Scrum Board. Still, the ideal is to break flow and to handle the bug immediately, rather than using the information radiators to schedule the repair. The team should establish the discipline that repairing defects is always highest priority, because defects add drag on velocity, may hide other defects, and tend to be forgotten if deferred.
If a bug cannot be fixed within one day, then that may indicate a more serious problem with the product. After all, no bug should take very long to fix. If the repair interval crosses some pre-determined threshold (usually a half-day or a day) of effort, the issue should be escalated via the Scrum Emergency Procedure. Causes of such bugs should be discussed in Sprint Retrospectives.
It is still usually necessary to have a bug reporting mechanism for customers to write up bugs. If you have one, use it only as a holder for bug reports that have not been examined yet. Once you examine a bug report, handle it immediately as described above. Resist the urge to read it and leave it in the bug reporting system to be handled later.
Note that while the focus of this pattern is on fixing bugs, one should also treat refactoring the same way. After all, refactoring is a way of cleaning up the code, and at the end of the day, the code should be as clean as possible. Like bugs, deferred refactoring leads to technical debt.
How does this help velocity?
If a team already maintains a bug list, then moving to this pattern will be painful and require a lot of work. However, fixing bugs immediately can reduce the time needed for testing. Since testing is often a delivery bottleneck, deployment will go faster. For these reasons, it is good to immediately fix bugs discovered in a Sprint. The Developers and Product Owner together should develop a plan to reduce latent technical debt caused by past unfixed bugs and undone work.
This is a radical break from the traditional way of thinking. Teams that maintain a bug list must not only eliminate their existing bug list, but must change their way of thinking. Strong commitment from the team is needed, along with constant reminders, especially from the Scrum Master (see DoneMaster and Sheepdog).
The source of data on this is a paper on Scrum and CMMI  where a CMMI Level 5 company drove the doubling of productivity on every time using control charts that manages bug fixes to less than a day (ideally averaging two hours).
Good Housekeeping is not only cleaning up your own stuff but also that of others. Robert Stephenson Smyth Baden-Powell, the father of Scouting, stated: "Try and leave this world a little better than you found it." Today, Scouts say, "Leave the campground cleaner than when you found it."  The same applies to leaving the product and shop floor cleaner than they were when you started. You can help achieve Good Housekeeping with Whack the Mole.
 C. Jakobsen and J. Sutherland, 2009, Scrum and CMMI – Going from Good to Great: are you ready-ready to be done-done?, proceedings of Agile 2009, Chicago
 Lord Baden Powell, cited at http://www.biographyonline.net/humanitarian/baden-powell.html.
Value Stream >