Cuando la deuda técnica de un componente impide un desarrollo fluído ya sea porque se requiere un mayor esfuerzo y/o porque la posibilidad de que se produzcan efectos colaterales es muy alta o cuando el usuario advierte que el producto tiene alguna deficiencia funcional en un aspecto fundamental de su funcionamiento es el momento de plantearse el dar una solución a esos problemas antes de continuar con la evolución del producto.
Huir hacia adelante no suele funcionar bien en el desarrollo de software porque el problema no se elimina de esa forma y por el coste que tiene arrastrar con esa deuda técnica y/o esas deficiencias.
Desde mi punto de vista esa decisión no debe ser tomada unilateralmente por el desarrollador sino que debe ser consensuada con el responsable funcional, product owner o como queremos denominarlo porque es responsabilidad del mismo definir la línea de desarrollo del producto y, si vamos a realizar acciones que van a ralentizar la evolución del producto (a corto plazo), debe ser consciente de ello y autorizarlo.
Si la tarea de refactorización puede desarrollarse dentro de la iteración se consideraría como una tarea más de la misma y se ejecutaría sin más (avisar o no al product owner dependería de las políticas que, al respecto, se tuvieran definidas en el proyecto).
Jummp 