Nuestra empresa está experimentando con Scrum, y tengo una pregunta rápida sobre de qué debe estar compuesto exactamente un sprint.
Después de la reunión de planificación del sprint, nos decidimos por tres historias diferentes. Una historia se sostiene por sí sola y se puede terminar y lanzar al final del sprint. Los otros dos, sin embargo, son piezas más pequeñas de una característica más grande.
¿Es común dividir el tema conceptual de un sprint como este, o todas las historias deberían centrarse en la característica principal?
Idealmente, un Sprint debería proporcionar un incremento coherente de funcionalidad. En la práctica, los equipos pueden generar historias que no están alineadas con el Sprint Goal singular, pero esto requiere un Scrum-fu avanzado. Incluso cuando se extraen historias adicionales, algunas estrategias son más exitosas que otras, y se debe tener mucho cuidado de no violar los principios básicos de Scrum al hacerlo.
Uno de los requisitos más ignorados del marco Scrum es la necesidad de un Sprint Goal para guiar cada iteración. La definición canónica del Sprint Goal se describe aquí:
El Sprint Goal es un objetivo establecido para el Sprint que se puede cumplir mediante la implementación de Product Backlog. Brinda orientación al Equipo de desarrollo sobre por qué está construyendo el Incremento. Se crea durante la reunión de Planificación de Sprint. El Sprint Goal le da al Equipo de Desarrollo cierta flexibilidad con respecto a la funcionalidad implementada dentro del 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.
— La Guía Scrum , Schwaber y Sutherland, p.10
El texto requiere un poco de análisis, pero el concepto central es que un Sprint Goal es la base de la iteración. Un Sprint no falla o tiene éxito en función de cuántas historias se hayan hecho o no al final del Sprint; el éxito solo viene de cumplir el objetivo definido por el Sprint Goal.
Si su Sprint Goal es "hacer un montón de historias" o "completar esto, aquello y alguna otra cosa", entonces pierde la esencia misma de la agilidad. El equipo no puede trabajar con el propietario del producto y las partes interesadas para encontrar una forma óptima de alcanzar el objetivo establecido; en cambio, el equipo se ve obligado a encontrar el éxito solo a través de la finalización al 100% de los paquetes de desglose de trabajo prescriptivos.
Cada Sprint debe tener un Sprint Goal único, y el éxito del Sprint se basa en si el Sprint Goal se cumplió al final de la iteración. Sin embargo, debido a que un Sprint es un cuadro de tiempo de duración fija, a veces el equipo tendrá capacidad adicional disponible después de alcanzar la Meta del Sprint. Esto lleva a varias opciones.
La primera opción es que el propietario del producto solicite una finalización anticipada del Sprint. Si tiene un Sprint de un mes, pero alcanza su Sprint Goal en una semana, esto es ciertamente algo sensato. Sin embargo, las terminaciones anticipadas conllevan una sobrecarga del proceso, por lo que si se encuentra con esta situación a menudo, debe reducir la duración de su Sprint y reservar las terminaciones anticipadas para circunstancias realmente anormales.
La segunda opción es asegurarse de que el equipo solo se comprometa con las historias relacionadas con el Sprint Goal actual, pero use cualquier capacidad adicional restante después de alcanzar el Sprint Goal para eliminar historias adicionales del Product Backlog. Obviamente, esto se hace en cooperación con el Product Owner, quien trabaja con el equipo para identificar historias de usuarios que:
La estrategia Llenar el exceso de capacidad es la que los equipos experimentados generalmente encuentran más efectiva. Conserva la integridad del Sprint Goal y mantiene estable la cadencia iterativa, pero también proporciona la flexibilidad que tanto necesita el proceso. Recuerde, los Sprints tienen que ver con mantener un ritmo de desarrollo sostenible a lo largo del tiempo, y la primacía del Sprint Goal es una de las formas más efectivas de establecer ese ritmo correctamente.
Por supuesto, algunos equipos son víctimas de la falacia de utilización del 100 % y asumen que el objetivo es mantener el equipo trabajando a plena capacidad en cada iteración, independientemente de la necesidad de un proceso lento o de objetivos comerciales flexibles. Dichos equipos normalmente completarán su Sprint hasta el tope en función de los patrones de velocidad históricos o los objetivos de gestión arbitrarios.
Hay muchos problemas con este enfoque, incluido un enfoque reducido en el incremento del producto y una capacidad reducida para adaptarse a los objetivos comerciales cambiantes. También hace que sea muy difícil para un equipo determinar si un Sprint determinado fue un éxito o no. Al final de un Sprint, incluso si completó el 100 % de las historias y mantuvo a todos ocupados el 100 % del tiempo, sin un objetivo cohesivo, ¿cómo sabe que construyó lo correcto?
En algunos dominios, esta regla marco se puede romper con éxito, pero ciertamente complica enormemente el proceso. Si su Scrum-fu está lo suficientemente avanzado como para romper esta regla aprovechando sus ciclos de inspección y adaptación, midiendo el éxito correctamente y manteniendo un ritmo sostenible, bueno, adelante.
Ciertamente, hay casos en los que múltiples objetivos o la planificación de Sprint de objetivos cruzados pueden funcionar, pero es como hacer malabarismos con motosierras. No lo recomiendo, a menos que esté planeando usar su acto de malabarismo que desafía a la muerte para unirse al circo, por supuesto.
La forma en que lo he visto hecho (actualmente estoy trabajando en una gran empresa haciendo escalado ágil) es que el trabajo realizado en un sprint se basa en la capacidad y la prioridad, no necesariamente en un tema. Con frecuencia tenemos características que se descomponen en múltiples historias que no necesariamente se completarán en un solo sprint, particularmente cuando tenemos dependencias en otros equipos (por ejemplo, necesitamos un servicio construido/modificado).
Así que no veo ningún problema con el enfoque que estás tomando.