He trabajado en equipos que, mientras usaban Scrum, se han adherido a esta opinión: cada historia debe estar completa al final del sprint.
¿Cuál es la definición/requisito "oficial"?
Me esfuerzo por tener todas las historias completas al final del sprint y reconozco que las historias no se deben incluir en los miembros del equipo inactivos si no hay suficiente tiempo para completarlas, de modo que un producto con características completas es ideal para la revisión del sprint.
Sin embargo, en el mundo real es casi imposible garantizar que todos los miembros del equipo (en mi caso, los desarrolladores) no estén inactivos durante al menos un día, dado que nuestro equipo abarca 3 zonas horarias muy dispares y efectivamente no hay un solo "final". de tiempo de sprint" o "inicio de sprint".
Usted dice que algunos equipos creen lo siguiente:
[C]ada historia debe estar completa al final del sprint.
Puede ser cierto que algunos equipos crean en este concepto erróneo común, pero en realidad es incorrecto. El marco Scrum requiere que el Equipo Scrum haga todo lo posible para entregar un Sprint Goal coherente en cada Sprint. Las historias de usuario (o, más canónicamente, los elementos de la cartera de productos) son medios para un fin, en lugar de un fin en sí mismos.
Recuerde siempre que el objetivo de un Sprint no es completar muchos elementos pendientes. El objetivo de un Sprint es entregar el Sprint Goal .
La Guía de Scrum dice explícitamente (énfasis y cursivas mías):
Los elementos del Product Backlog seleccionados ofrecen una función coherente , que puede ser el Sprint Goal. El Sprint Goal puede ser cualquier otra coherencia que haga que el Equipo de Desarrollo trabaje en conjunto en lugar de en iniciativas separadas .
Por lo tanto, tener muchas historias de usuarios que se tratan como iniciativas independientes que deben completarse al final del Sprint para que el Sprint tenga éxito es un antipatrón. También está explícitamente prohibido según la Guía de Scrum. Ciertamente, es común ver este patrón en las tiendas que luchan con la adopción ágil, pero el hecho de que sea común no lo hace ágil (y ciertamente no es Scrum).
La pregunta es si el equipo aún puede cumplir con el Sprint Goal si ciertas historias no se inician o si permanecerán incompletas al final del Sprint. La única forma de averiguarlo es preguntándole al equipo Scrum y luego realizar un seguimiento del progreso hacia el Sprint Goal en su tabla de trabajo pendiente, tablero Kanban, Sprint Backlog u otros artefactos. El Dueño del Producto tiene la capacidad de renegociar el alcance del Sprint, o de cancelar el Sprint y regresar a la Planificación del Sprint, siempre que el Objetivo del Sprint actual esté en riesgo.
Los siguientes elementos del marco Scrum se definen explícitamente en The Scrum Guide. El Objetivo del Sprint se desarrolla durante la Planificación del Sprint y proporciona orientación a lo largo del Sprint. El Incremento es el trabajo completado de acuerdo con la Definición de Terminado, y es esencialmente el entregable de facto para el Sprint.
Los elementos del Product Backlog seleccionados ofrecen una función coherente, que puede ser el Sprint Goal. El Sprint Goal puede ser cualquier otra coherencia que haga que el Equipo de Desarrollo trabaje en conjunto en lugar de en iniciativas separadas.
Al final de un Sprint, el nuevo Incremento debe estar "Terminado", lo que significa que debe estar en condiciones de uso y cumplir con la definición de "Terminado" del Equipo Scrum. Debe estar en condiciones de uso, independientemente de si el propietario del producto decide lanzarlo.
Si bien no se aborda específicamente en The Scrum Guide, en la práctica, un Sprint realmente tiene solo tres condiciones de falla:
Eso es todo. Las historias individuales se pueden hacer o no hacer, los pronósticos (estimaciones) se pueden perder y el equipo puede haber entregado con éxito el MacGuffin equivocado. Dichos Sprints siguen siendo técnicamente "exitosos" en el sentido de que entregaron un Incremento potencialmente liberable y aprovecharon el marco para brindarle al negocio transparencia de procesos y oportunidades apropiadas para inspeccionar y adaptar.
Aziz jeque