¿Las tareas o historias "casi terminadas" justifican la planificación con sobrecarga en el próximo sprint?

El caso en cuestión:

El sprint casi ha terminado y uno de mis equipos Scrum no terminó algunas tareas. (La razón de esto no es esencial para esta pregunta y se abordará en consecuencia.) Uno de ellos es un caso clásico de "90% hecho" con una cantidad bastante grande de puntos de historia y será parte del próximo sprint, como en el cuestionar aquí .

Retrasamos la preparación y algunas estimaciones preliminares para el próximo sprint y discutimos cómo manejar esta tarea inacabada. Si bien todos estamos de acuerdo en que no contará para la velocidad de este sprint, sostuve que no deberíamos volver a estimar el caso casi completo con 1 en lugar de cinco puntos de historia, porque quiero que la verdadera complejidad y el trabajo total realizado sean Aún visible. Y mirando hacia atrás, la estimación fue correcta. - Solo estamos haciendo la transición a ágil (escalado) y algunos niveles de gestión necesitan "ver" que aún somos productivos en más formas que los productos entregados.

Obviamente, la velocidad en este sprint disminuirá, pero las partes transferidas "ya hechas" deberían aumentarlo nuevamente el próximo sprint.

Hasta ahora todos estamos de acuerdo.

Pero como nuestros equipos son bastante pequeños, cuatro puntos es un gran bulto. Sugerí que solo para esta tarea y con la documentación adecuada , podríamos planificar conscientemente una sobrecarga de cuatro puntos.

¿Es un enfoque factible o lo haré?

• me encuentro con problemas que aún no anticipo
• ¿Poner un mal ejemplo con un equipo que ha sido transferido a ágil hace solo unos meses?

Cuando una historia no se realiza al final del sprint, los puntos de la historia no cuentan para la velocidad de ese sprint y la historia vuelve al registro de reserva.

Si durante la planificación del próximo sprint se selecciona la historia para que esté terminada, entonces puede hacer una nueva estimación rápida del trabajo restante. Esta estimación solo debe usarse durante la sesión de planificación para asegurarse de que no está subcargando el sprint con historias con una gran cantidad de puntos en los que realmente se necesitan muy pocos trabajos para completarlos.
En el tablero (y en la velocidad del nuevo sprint), se debe usar la estimación original de la historia que se transfirió.

Tales historias arrastradas son una de las razones por las cuales la velocidad puede variar de un sprint a otro y debes usar un promedio para calcular la capacidad del equipo al planificar un sprint.

Si la historia no completada no se retoma en el próximo sprint, entonces podría ser mejor planificarla para el valor total de los puntos cuando se retome de nuevo, porque también tomará tiempo para ponerse al día de nuevo con lo que era el estado cuando el equipo dejó de trabajar en él.

No intentes hacer que tu velocidad se vea mejor de lo que es. El camino a seguir es reconocer que la tarea no se completó, sobreestimó lo que podía hacer en el sprint y falló. Pero así es la vida y una oportunidad para aprender.

Entonces 0 puntos por la tarea incompleta.

En cuanto al nuevo sprint, calcule el trabajo necesario para completar la tarea en puntos de historia y cuente como una tarea normal.

Le preocupa que su velocidad se vea demasiado baja, debería preocuparse de que su velocidad sea artificialmente demasiado alta.

Tener una velocidad que es más alta de lo que realmente puede lograr lo preparará para el fracaso una y otra vez.

En nuestro equipo utilizamos algunas formas diferentes de manejar las historias de traspaso, según las circunstancias.

• Cuando el sprint está casi terminado y todo lo planeado ya está terminado (lo que sucede cada dos sprint), entonces comenzamos con las siguientes historias en la lista de pedidos pendientes (pero no los comprometemos con el lanzamiento del sprint). Estos se incluyen automáticamente en el próximo sprint, y para fines de informes, todos los puntos de la historia pasan al siguiente sprint.

• Cuando partes de la historia están completamente terminadas y tienen valor comercial por sí mismas, en general reajustamos tanto el alcance como la estimación de la historia original, y las partes restantes vuelven a la cartera de pedidos.

• Si la estimación original de la historia estaba desactivada (lo que a veces sucede para historias grandes y complejas), tratamos de aprender de ella :). No hay puntos de historia en el sprint actual, vuelva a estimar toda la historia en la próxima planificación del sprint.

Cuando algunas de las historias se transfieren del sprint anterior, en la planificación del sprint no comienzas con una reserva de sprint vacía. El equipo decide cuánto trabajo adicional pueden tomar además de eso. Por ejemplo: la capacidad normal del equipo es de 100 SP / sprint, 20 puntos ya en progreso, el equipo decide tomar 90 SP nuevos, por lo que tiene 110 SP en el sprint al comienzo del sprint.

El principal inconveniente de este enfoque es que los informes de velocidad no son tan buenos como a algunos de los gerentes les gustaría que fueran. Pero a la larga todo se iguala, y de esta manera todo lo que es potencialmente liberable se entrega lo antes posible, y el equipo obtiene créditos por su trabajo.

Un poco de historia: originalmente este equipo tenía un enfoque muy estricto para los plazos de sprint, por lo que se negarían a asumir historias más grandes de las que podrían terminar en la primera semana (del sprint de 2 semanas), y usar pequeñas y seguras trabajar para la parte restante del sprint. Si bien esto dio como resultado un buen retraso en el sprint vacío al final del sprint, esto tuvo demasiada influencia en la pregunta '¿en qué trabajaremos a continuación?'.

Esta no es una pregunta para una respuesta fácil. Habrá muchas opiniones sobre qué hacer, pero le sugiero que comience con la identificación de las diversas necesidades que tiene que satisfacer y proponga una solución basada en ellas. Ejemplo:

1. Un equipo "necesita" comprender cómo están trabajando e identificar cualquier oportunidad de mejora. A veces, cambiar los puntos de la historia enmascara los problemas que deben abordarse.
2. El propietario del producto "necesita" poder saber cuántos puntos de historia se estimaron para una característica (a menudo estos se agregan a nivel de característica) o versión (AKA "PI" en SAFe-speak) y puede solicitar una quema en el nivel de característica (o PI) para demostrar el progreso hacia la entrega de un MVP o MMF. Cambiar los puntos de la historia puede sesgar los números y causar cierta confusión.

Hay algunas "barandillas" para ayudar a guiar la decisión.

• El trabajo está HECHO o no. El trabajo incompleto no cuenta para el sprint en el que se completó.
• Las historias incompletas deben ser re-priorizadas (no es un "dado" que se trasladen al próximo sprint, pueden regresar al trabajo atrasado o ser abandonadas).

Dicho esto, he visto a muchos equipos manejar esto de varias maneras.

1. Si la historia incompleta sigue siendo válida y aprobada por el PO, toda la historia pasa al siguiente sprint. Lo que estos equipos hacen a menudo es TAG estas historias a medida que se transfieren y estiman cuántos puntos de "trabajo restante" representan. Entonces, si se trata de una historia de 13 puntos, pero solo le queda 1 punto, hacen los cálculos para ajustarse a eso restando 12. Esto deja la estimación original para fines históricos como usted sugirió, mientras ayuda al equipo a determinar su capacidad. En este caso, SÍ, puede tener "más puntos" que su "umbral" de capacidad basado en la velocidad. Pero la velocidad puede cambiar ligeramente, no está escrita en piedra.
2. He visto equipos dividir la historia (Rally, por ejemplo, tiene una funcionalidad muy buena para esto), y aplicar algunos puntos para la parte de la historia que "permanece" en el viejo sprint y luego aplicar puntos a la parte que se lleva adelante. Este enfoque es conveniente, pero viola el principio de que "Listo significa HECHO", y oculta el hecho de que las estimaciones pueden ser pobres y el trabajo se está transfiriendo, por lo que se puede perder la oportunidad de aprender y mejorar. (Esta no es mi recomendación por esas razones)
   3. La peor solución que vi fue que simplemente marcaron la vieja historia HECHO, tal vez redujeron los puntos, tal vez no, y luego abrieron una nueva historia para el trabajo restante (¡a menudo probando!). Esta es una solución fea por cualquier estándar, en mi humilde opinión.

En lo que me centraría es en esto: "Uno de ellos es un caso clásico de" 90% hecho "con una cantidad bastante grande de puntos de historia". ¡La clave aquí es la historia GRANDE! Recuerde INVERTIR: las historias deben ser PEQUEÑAS. El equipo debe considerar dividir historias (preferidas) o enjambrarlas. Pero más grande siempre significa más riesgo, incluso cuando está enjambrado.