¿Cómo se modifica una historia de usuario entregada?

TL;DR

Si entrega una historia de usuario en un sprint anterior y luego necesita modificarla en un nuevo sprint, ¿qué hace?

tu no Todo el trabajo debe ser priorizado por el Product Owner en el Product Backlog, y no se deben introducir historias no planificadas en la iteración actual después de que se complete la Planificación de Sprint.

Si descubre trabajo que debe realizarse en un sprint futuro, escriba una nueva historia de usuario y envíela al propietario del producto para que la incluya en la cartera de productos. Si es realmente un obstáculo que bloquea el progreso dentro del sprint actual, plantee el problema dentro del equipo (por ejemplo, durante la reunión diaria) y deje que el Scrum Master lo escale.

Refactorización frente a trabajo nuevo y reelaboración

La refactorización no cambia el comportamiento de una característica, solo cambia la implementación interna. Es posible que deba refactorizar el código existente para acomodar una nueva característica, pero el código anterior debería comportarse fundamentalmente de la misma manera, y todas sus pruebas anteriores aún deberían pasar.

Además, dichas refactorizaciones deben mantenerse al mínimo absoluto necesario para adaptarse a la nueva característica. Este no es el momento de volver atrás y hacer mejoras u optimizaciones que se extiendan más allá del alcance de la historia en la que está trabajando.

Si necesita cambiar el comportamiento, mejorar una interfaz de usuario u optimizar una sección de código, eso es trabajo nuevo . Debe agregarse al Product Backlog, priorizado por el Product Owner durante la Preparación del Backlog, y luego agregarse al Sprint Backlog durante la Planificación del Sprint para un sprint futuro en lugar del actual.

Siempre hay excepciones

Hay excepciones a cada regla. Algunos ejemplos incluyen:

1. Es posible que durante un sprint se descubran nuevos trabajos esenciales para el objetivo del sprint actual, lo que podría justificar una terminación anticipada y un regreso a la planificación del sprint.
2. Pagar la deuda técnica cuando no tiene otras historias en las que trabajar es un buen uso del tiempo.
3. Refactorizar (o incluso mejorar) algo de pasada mientras se trabaja en una función entregable suele estar bien en la práctica, pero es una línea muy fina que a menudo conduce a un afeitado de yak y quita recursos de las historias con las que el equipo se ha comprometido para el sprint. No hagas eso.
4. Las historias que no están en la ruta crítica hacia el Sprint Goal se pueden intercambiar, modificar o eliminar del alcance con la cooperación activa del propietario del producto sin desencadenar una terminación anticipada. Esta es una técnica avanzada que puede fracasar fácilmente, así que no confíes en ella.

Scrum y otros marcos ágiles no están destinados a ser una camisa de fuerza. Hay suficiente flexibilidad en el sistema para acomodar variaciones y casos extremos. Sin embargo, un equipo realmente necesita dominar los principios subyacentes antes de intentar violar principios como YAGNI o eludir los controles de alcance formales, o de lo contrario corre el riesgo de convertir su marco en ScrumBut o su equivalente que induce fallas.