En nuestra organización, usamos la velocidad para pronosticar la cantidad de trabajo posible en un Sprint. A veces, en función de la velocidad promedio del equipo, agregamos funciones adicionales que no están relacionadas con el Sprint Goal, solo para agregar más valor si las tareas del Sprint Goal no son suficientes.
A veces, estas funciones adicionales no se pueden completar y tenemos que finalizar el Sprint como un Sprint fallido porque no pudimos completar las expectativas de las partes interesadas.
¿Es posible eliminar Historias, incluso en un Sprint en ejecución?
Al definir el éxito como "hacer todas las cosas", en lugar de "hacer las cosas correctas ", su proceso inherentemente prepara al equipo para el fracaso. En su lugar, aproveche el marco (especialmente el Sprint Goal y la Definición de Listo ) para medir correctamente el valor que el equipo está entregando.
A veces, estas funciones adicionales no se pueden completar y tenemos que finalizar el sprint como un sprint fallido porque no pudimos completar la expectativa de las partes interesadas.
Esto está mal. Dejando a un lado la cuestión de si debe aceptar trabajo en un Sprint que no esté relacionado con el Objetivo del Sprint, no completar el "trabajo adicional" no significa que tenga un Sprint fallido.
La tautología Scrum de CodeGnome dice:
Recuerde siempre que el objetivo de un Sprint no es completar muchos elementos pendientes. El objetivo de un Sprint es entregar el Sprint Goal.
Ignorar la tautología es un aspecto de la falacia de utilización del 100 % . Centrarse en la cantidad de trabajo que hace el equipo, en lugar de en la forma predecible en que entregan incrementos de productos de trabajo, es un mal olor de implementación del marco.
Un Sprint exitoso es aquel que cumple con el Objetivo de Sprint definido y ofrece un incremento potencialmente entregable según la Definición de Terminado. Cualquier otra definición es autosabotaje.
La sección de la Guía de Scrum sobre la Teoría de Scrum ni siquiera reconoce el concepto de un "Sprint fallido". En su lugar, trata los problemas de proceso o entrega como oportunidades de inspección y adaptación. Dice:
Si un inspector determina que uno o más aspectos de un proceso se desvían fuera de los límites aceptables y que el producto resultante será inaceptable, se debe ajustar el proceso o el material que se está procesando. Se debe hacer un ajuste tan pronto como sea posible para minimizar más desviaciones.
En principio, esto significa que la única "falla" es la falta de aplicación de los principios de Scrum, como establecer un Sprint Goal coherente, renegociar el alcance con el Product Owner según sea necesario o cancelar un Sprint cuando sea necesario.
Para responder a su pregunta en un nivel básico, si desea cambiar el alcance del sprint mientras se ejecuta el sprint, los elementos del backlog que cambie deben tener un tamaño equivalente. Por ejemplo, si necesita agregar una historia de 5 puntos al sprint, puede eliminar una historia de 5 puntos del sprint. O bien, puede eliminar una historia de 2 puntos y una historia de 3 puntos. Por lo tanto, el compromiso de sprint sigue siendo el mismo: no estás haciendo trabajo extra.
No dijiste si estabas haciendo esto o no, pero no elimines nada del sprint si está marcado como en progreso, ya que esto interrumpirá el trabajo del equipo.
Alcanzar el objetivo del sprint debe ser tu objetivo. Si hay cosas adicionales que le gustaría que hiciera el equipo si superan el trabajo pendiente del sprint más rápido de lo esperado, considere tenerlas como metas amplias. Con este método, no necesita agregarlos directamente al sprint y no necesita quitar nada. Si el equipo completa el trabajo pendiente del sprint antes, podría tomar el elemento de mayor prioridad de la lista de objetivos ambiciosos y llevarlo al sprint. Debe ser algo que se pueda completar dentro del sprint, así que tenga cuidado al agregar elementos grandes hacia el final del sprint. Si los objetivos ambiciosos no se completan, el sprint no ha fallado. Los objetivos de estiramiento son trabajo adicional, no son sus objetivos de sprint.
Fallar en un sprint puede ser muy desmoralizador para el equipo, y parece que podría evitarse si sucede debido a elementos agregados al sprint que no se relacionan con el objetivo del sprint.
Si las partes interesadas solicitan más trabajo mientras se ejecuta el sprint, todo lo que debe hacer es decir que el trabajo se puede considerar para un sprint futuro.
Sería útil saber cuál es tu papel, ya que no lo dijiste. Aunque esa podría ser otra pregunta.
Daniel
erik
josebel luna