Siempre empieza igual.
El ticket llega al sprint planning. Alguien dice «es rápido, dos días máximo». Todo el mundo asiente. Nadie hace preguntas. El ticket entra en el sprint con una estimación de 3 puntos y una energía colectiva de «esto lo resolvemos rápido».
Tres semanas después, el ticket sigue ahí.
«Quick win» es la mejor promesa del desarrollo de producto. Y la más mentirosa.
No por mala fe. Por optimismo. Por ganas de hacer bien las cosas. Por esa vocecilla que dice que esta vez será sencillo, que el código está limpio en esa zona, que nadie ha tocado ese módulo desde hace tiempo así que debe estar estable.
Spoiler : el código nunca está limpio en esa zona. Alguien siempre ha tocado ese módulo. Y «hace mucho que nadie ha entrado ahí» es exactamente la razón por la que va a llevar tiempo.
Estimar no es predecir. Es narrar.
Cuando un desarrollador dice «dos días», está contando una historia. La historia de un mundo ideal donde las specs son claras, las dependencias son conocidas, los tests están escritos y el resto del sprint está vacío.
Ese mundo no existe.
El problema real es que todo el mundo lo sabe. El dev que estima. El PO que valida. El Scrum Master que anota. Y aun así, nadie dice nada. Porque cuestionar una estimación en el sprint planning es socialmente incómodo. Ralentiza la reunión. Da la sensación de bloquear al equipo.
Así que apuntamos 3 puntos y ya veremos.
Ya vemos. Tres sprints después.
Esto es lo que pasa realmente con un «quick win» que se tuerce. Primer sprint : la tarea empieza, se descubre una dependencia no documentada. Bloqueo. Aplazamiento. Segundo sprint : se retoma, pero un bug crítico en otro sitio acapara a los devs. El ticket espera. Tercer sprint : se termina, pero los tests revelan un efecto secundario. Corrección, re-test, merge tardío.
Nueve semanas por una estimación de dos días. La velocidad sufre. Y nadie entiende del todo por qué no se cumplió el sprint.
La deuda técnica son los intereses de cada quick win mal estimado.
Cada atajo tomado para entregar rápido se convierte en una restricción para el siguiente ticket. Y el siguiente. Hasta que todo «quick win» se transforma automáticamente en investigación, porque el código está tan cargado de historia no documentada que ningún cambio puede ser realmente rápido.
Eso es la deuda técnica. No un concepto abstracto de conferencia tech. Tickets estimados en 3 puntos que acaban en 13.
¿Y si borramos «quick win» de nuestros backlogs?
No porque la intención sea mala. Porque la palabra crea una expectativa que contamina la estimación antes de que empiece la conversación.
Un spike de investigación antes de estimar. Honestidad colectiva sobre lo que todavía no sabemos. Y la aceptación de que querer que algo sea rápido no lo hace rápido.
Tu próximo sprint planning merece esa conversación.
Entonces, ¿lo destierras o te lo quedas?