El sprint de endurecimiento es una confesión, no una cura
Cada cierto tiempo un equipo anuncia que necesita un "sprint de endurecimiento": un Sprint apartado para corregir errores, integrar componentes, terminar las pruebas y, en general, dejar el producto listo para publicar. Suena responsable. En realidad es una admisión. Un Sprint de endurecimiento es el equipo diciéndote, en voz alta, que el trabajo que llamó "terminado" en los Sprints anteriores no lo estaba de verdad. En un marco cuya premisa entera es un Incremento utilizable y publicable al final de cada Sprint, eso merece tomarse en serio.
La Guía de Scrum es directa al respecto: cada Sprint debe producir un Incremento que cumpla la Definición de Terminado, y esa definición es la descripción compartida y formal del equipo sobre la calidad requerida para que el producto sea publicable. Si un Incremento no la cumple, no puede publicarse y, sobre todo, no debería presentarse como completo. No existe disposición alguna para que un Sprint posterior haga aceptable de forma retroactiva el trabajo anterior. El endurecimiento no es más que una Definición de Terminado aplazada, reempaquetada como plan.
Qué se ve bien
En un Equipo Scrum sano, el "terminado" no se negocia elemento por elemento, y la calidad se incorpora a medida que avanza el trabajo.
Cada elemento del Product Backlog que el equipo llama terminado ya cumple la misma Definición de Terminado: probado, integrado y documentado según lo exige la DoD.
Las pruebas, la integración y la revisión ocurren dentro del Sprint, junto con la construcción, no apiladas para después.
El Incremento mostrado en la Revisión del Sprint es genuinamente publicable; la decisión de publicar es de negocio, no una carrera técnica de último momento.
La deuda técnica es visible en el Product Backlog y se salda de forma deliberada, sin dejar que se acumule en silencio hasta exigir un Sprint dedicado.
Si el equipo no puede terminar un elemento conforme a la Definición de Terminado, queda como no terminado y vuelve al Product Backlog: no se da por bueno.
Qué se ve mal
El patrón de endurecimiento tiene una forma reconocible, y rara vez aparece solo.
Una Definición de Terminado débil u opcional. Los elementos se marcan como completos en cuanto el código compila y la demo funciona, dejando las pruebas y la integración como problema posterior de otro. La DoD existe en el papel pero no en la práctica.
Una velocidad que halaga. Los Sprints de funcionalidades parecen rápidos y productivos precisamente porque se saltan el trabajo de acabado; luego un Sprint de endurecimiento absorbe la factura. La velocidad reportada nunca fue real.
Integración big-bang. Los componentes se construyen de forma aislada y solo se conectan al final, de modo que el Sprint de endurecimiento se convierte en la primera vez que alguien averigua si el sistema realmente funciona.
Una fecha de publicación que dicta la verdad. Como la entrega está fijada a una fecha firme, la calidad pasa a ser la variable que cede, y "ya lo endureceremos después" se vuelve la salida de emergencia permanente.
Nótese que ninguno de estos es un fallo de herramientas. Es un equipo —a menudo bajo presión real de calendario, que la escasez de mano de obra de 2022 y los cambiantes planes de regreso a la oficina solo agudizaron— que redefine en silencio el "terminado" a la baja y lo paga de golpe más tarde. El Sprint de endurecimiento es donde ese coste aplazado por fin aterriza.
Atacar la causa, no el síntoma
El remedio no es planificar mejor el Sprint de endurecimiento. Es hacerlo innecesario. Refuerce la Definición de Terminado hasta que signifique de verdad publicable, y luego exíjala a cada elemento. Traiga las pruebas y la integración al Sprint, donde el trabajo está fresco. Convierta la deuda técnica en un elemento visible y priorizado del Product Backlog en lugar de un saldo oculto. Una vez que "terminado" signifique de forma fiable terminado, el Sprint especial de estabilización se queda sin nada que hacer, que es justamente el objetivo.
Si sus equipos de entrega descubren una y otra vez que necesitan un sprint para "terminar de terminar", la asesoría en entrega de programas y proyectos de XNM puede ayudarle a apretar la Definición de Terminado e incorporar la calidad donde corresponde.