Yes exactly. Any non-critical out of current scope bug must be evaluated for whether it should interrupt the current work. Is it a priority? You cannot automate this process by saying “if is_bug: return {priority: IMMEDIATE}” as suggested by the quote about id above, because you will absolutely destroy any velocity. In fact that quote seems to me to be talking about not committing new code with known bugs, not dropping everything as soon as a non-critical bug is discovered in old code.
Instead you need to have a triage process and a planning process, which to some degree most software teams do. The problem is that most of these processes do not have a rigid way of dealing with really old low priority bugs. A bug fix week is one option for addressing that need.
Yes exactly. Any non-critical out of current scope bug must be evaluated for whether it should interrupt the current work. Is it a priority? You cannot automate this process by saying “if is_bug: return {priority: IMMEDIATE}” as suggested by the quote about id above, because you will absolutely destroy any velocity. In fact that quote seems to me to be talking about not committing new code with known bugs, not dropping everything as soon as a non-critical bug is discovered in old code.
Instead you need to have a triage process and a planning process, which to some degree most software teams do. The problem is that most of these processes do not have a rigid way of dealing with really old low priority bugs. A bug fix week is one option for addressing that need.