Cancelar o cambiar un sprint

¿Cancelar un sprint? He estado allí, hecho eso.

Ser esclavo de un método nunca es bueno y, a veces, a pesar de toda la planificación, las cosas pueden salir mal. Realmente mal. Cuando eso sucede, lo más sensato es bajarse del tren antes de que caiga por el precipicio. De esa manera, todos pueden reagruparse, analizar la situación con calma, identificar qué salió mal, discutir formas de evitar que algo así vuelva a suceder y comenzar de nuevo. (Suponiendo que fuera evitable, a veces interviene todo el mundo. Hacks, desastres de infraestructura, clientes que se van al sur, etc., etc.)

Más comúnmente, sin embargo, he visto a un solo equipo tener su sprint completamente reorganizado. Por lo general, porque los miembros del equipo se vieron obligados a lidiar con una emergencia o surgió algo de alto perfil. En este caso, las historias se volvían a seleccionar para el equipo restante o se reescribían (es decir, se dividían) para adaptarse mejor a la experiencia restante.

En pocas palabras: los sprints son una herramienta, un medio para un fin. A veces, por una miríada de razones, no te llevarán allí.

Esto se reduce a cómo desea ejecutar el proyecto y quién pagará el "costo" del sprint cancelado. Al final, puede haber razones válidas para cancelar todo el sprint y "dejar de lado" todo el código creado hasta la fecha y comenzar de nuevo.

Recomendaría reunir a las partes interesadas en la sala y hacer la pregunta difícil: si vamos a cancelar este sprint y desechar el trabajo que se ha realizado, quién cubrirá el costo. Esto tiende a obtener el enfoque que necesita y puede remodelar el sprint para salvar parte o todo el trabajo realizado o confirma su decisión de cancelar el sprint.

Al final, como dijo Gary, los Sprints son una herramienta/conjunto de reglas. Me gustan las reglas, ayudan a guiar a los desarrolladores, clientes y PM a tomar las decisiones correctas: cancelar un sprint puede ser la decisión correcta y, a menudo, puede ser mejor que cambiar los objetivos del sprint a largo plazo.

Los sprints se pueden cancelar como terminación anormal, por ejemplo, el equipo podría cancelar si no puede alcanzar la meta. El siguiente paso es tener una nueva reunión de planificación de sprint.

Los sprints pueden y deben cancelarse si existe una necesidad comercial legítima para ello.

Mantener el contenido de un Sprint estático es bueno para la cordura de su equipo y, en general, útil para la planificación.

Para lo que es realmente poderoso es para proteger al equipo de desarrollo del avance del alcance por parte de las partes interesadas que pueden pasar y solicitar nuevas funciones, etc. Si cada vez que esto sucede, marca ese sprint como terminado anormalmente, está creando un registro para comunicarse. al resto de la gerencia.

Si está revisando el progreso de sus proyectos con el liderazgo y muestra que Sprint 15 y Sprint 16 se terminaron porque la parte interesada Xyz solicitó características adicionales, esto generará señales de alarma para mostrar que la planificación no es adecuada, la visión no es clara/consistente o La parte interesada Xyz está jugando demasiado con el equipo.

Además, dejará en claro el impacto de agregar un nuevo alcance a un sprint para una parte interesada y hará que sea menos probable que interfieran o que esperen hasta el momento adecuado para influir en el cronograma de desarrollo (por ejemplo, reunión de planificación del sprint).

Agile no es anarquía, sino que funciona proporcionando una estructura en torno a la agilidad y, por lo tanto, definiendo los límites de cuán ágil puede ser.