¿Qué son los "puntos de historia consumidos" en Trello?

Puntos de historia consumidos: un antipatrón ágil

Los "puntos consumidos" son una especie de métrica de quemado que algunos profesionales usan para rastrear el progreso de una historia en comparación con sus estimaciones originales. Está destinado a mostrar el porcentaje de trabajo completado, estimar los excesos o reducir la necesidad de comunicación colaborativa sobre el estado de la historia.

En mi práctica de coaching, el uso de puntos consumidos se considera un antipatrón Scrum/Kanban. Las estimaciones de puntos de historia no son válidas fuera del propio proceso de estimación y no tienen ninguna utilidad fuera de Sprint Planning o Release Planning. Deben ser tratados como valores efímeros, y deben ser:

1. Creado, revisado o revisado durante la Planificación de Sprint.
2. Discutido durante Sprint Retrospectives como una forma de refinar el proceso de estimación y planificación del equipo.
3. Se descarta junto con el cuadro de tiempo, excepto como un total agregado para usar en la métrica de velocidad.

Veamos un ejemplo concreto y discutamos por qué las personas pueden usar los puntos consumidos y qué deberían hacer en su lugar.

Un ejemplo trabajado

Supongamos que está utilizando Trello con el popular complemento Scrum para Trello Chrome. Podrías tener un tablero como este:

Estimación del porcentaje completado

En la columna Trabajo en progreso, la historia se estima en cinco puntos de historia y el equipo calculó que se completó el 50 % del trabajo previsto. Teóricamente, eso significa que la historia en la segunda columna está a medio hacer.

¡Pero espera! En Scrum, como en la mayoría de los marcos ágiles exitosos, cada historia se hace o no se hace . Todo el marco está diseñado para alejarse de la falsa precisión y los informes de estado sin sentido que afirman que el 60% de algo está hecho en un 80%. En Scrum, una historia está terminada al 100 % (¡según la Definición de Terminado, por supuesto!) al final del Sprint, o simplemente está incompleta y debe devolverse a la Lista de Producto sin terminar, donde puede ser reescrita y priorizada. , reprogramado y replanificado.

Entonces, ¿por qué alguien usa los puntos consumidos? Las personas que lo hacen a menudo tienen razones, y esas razones generalmente se dividen en un par de categorías comunes.

1. Su proceso no es totalmente colaborativo, por lo que los "puntos consumidos" son una forma de evitar actualizaciones de estado más significativas. Desafortunadamente, "Llegué al 50%" no es particularmente útil, pero "Estoy trabajando en una historia que no puedo completar a menos que Alice haya terminado con su historia para agrandar el widget" sería claro y procesable.
2. El Scrum Master, el propietario del producto o una parte interesada externa está tratando de reemplazar los gráficos de quemado, las reuniones diarias u otras ceremonias y artefactos con métricas en una tarjeta. Los puntos de la historia son una herramienta de planificación, no una métrica de rendimiento, por lo que usarlos para cualquier otra cosa es inherentemente un mal uso de la métrica que produce información poco confiable.
3. El equipo y sus partes interesadas no comprenden completamente las estimaciones o pronósticos, y están tratando de vincular las estimaciones del nivel de esfuerzo con las horas de trabajo. Su suposición subyacente es que los puntos de la historia tienen tasas de conversión intrínsecas en el tiempo, y que cada historia tendrá una progresión estrictamente lineal desde el inicio hasta el final . Tampoco es el caso.

Cuando se hace correctamente, un Sprint Backlog se descompone en elementos hechos o no hechos que se pueden medir en el Sprint Burn-Down. Esta es una vista mucho más precisa de cuánto trabajo queda en el Sprint actual. Por el contrario, el porcentaje completo de historias es otra métrica indirecta subjetiva y funciona como un pronóstico secundario inexacto. Por ejemplo, si dices:

La historia del trabajo en progreso está terminada en un 50%, por lo que calculo que me llevará otros 5 días completarla.

todo lo que ha logrado es agregar un nuevo pronóstico basado en el tiempo (y en gran medida sin fundamento) además del pronóstico original del nivel de esfuerzo. La experiencia muestra que esto rara vez es preciso y casi nunca vale la pena rastrearlo. ¡"Hecho" o "no hecho" son las monedas del reino en marcos ágiles!

Seguimiento de excesos y estimaciones inexactas

El otro caso de uso se demuestra con la tercera tarjeta, ubicada en la columna Listo. En esa tarjeta, puede ver que el equipo estimó la historia en tres puntos de historia, pero luego afirma que se necesitaron ocho puntos de historia para completarla.

Si bien no hay nada de malo en señalar en una Retrospectiva de Sprint que la historia de un usuario se subestimó enormemente y usar la experiencia para mejorar el proceso de estimación y planificación del equipo la próxima vez, el valor de utilidad de rastrear formalmente la magnitud de la estimación errónea es cero. .

En una retrospectiva, es perfectamente razonable decir algo como:

Todos pensamos que esta historia era un 3 porque... pero resulta que no pensamos en las dependencias de foo , bar y baz . Además, tuvimos que reducir el tamaño para completar la historia, y no pensamos en crear un elemento de Sprint Backlog para eso o incluirlo en nuestras estimaciones. Tal vez necesitemos descomponer mejor historias como esta durante la Planificación de Sprint.

Sin embargo, un Sprint es una caja de tiempo efímera . Una vez que termina el Sprint, se va para siempre. O se cumplió el Sprint Goal, o no. O se completó una historia en ese Sprint, o no. Seis meses después, ¿importa si una historia dada fue más fácil o más difícil de completar de lo planeado originalmente? Por supuesto no.

Las verdaderas razones por las que las personas usan esta métrica post-hoc son:

1. La organización "responsabiliza" al equipo para mostrar cuánto esfuerzo están poniendo. Esto es especialmente común cuando no se cumplen los objetivos de Sprint y el equipo quiere decir "No completamos todas las historias necesarias". para alcanzar el Sprint Goal, ¡pero mira cuánto esfuerzo pusimos en Story X!"
2. El equipo trata incorrectamente la velocidad como una medida de productividad, en lugar de una medida de la capacidad histórica del equipo, e intenta jugar con la métrica para mejorar la óptica. "Estimamos esta historia en 3 puntos, pero en realidad tomó 8, ¡así que en realidad logramos 25 puntos de historia en lugar de 20 en este Sprint! Somos súper ejecutantes; ¡por favor no nos despidan!"
3. La alta gerencia está tratando incorrectamente la velocidad como un objetivo de rendimiento en lugar de una herramienta de pronóstico, e impulsa al equipo a asumir más trabajo del que puede ser sostenible. La estimación original puede haber sido establecida por el liderazgo en lugar del equipo, o las partes interesadas empujaron la historia al Sprint sin una descomposición suficiente. ¿Realmente desea rastrear métricas de velocidad separadas para cubrir un problema de proceso más profundo?

Revisar, no rastrear

Hay varias escuelas de pensamiento sobre si los equipos deberían ajustar los puntos de la historia dentro de un Sprint. Este es un tema complejo que está fuera del alcance de esta respuesta, pero la respuesta demasiado simplista es que, por lo general, es mejor dejar las estimaciones iniciales en paz si su objetivo es mejorar su proceso. Es mucho mejor (desde el punto de vista del proceso) decir "¡Oye, hicimos una estimación incorrecta! ¡Arreglemos eso la próxima vez!" en lugar de mover constantemente el queso.

La velocidad es una métrica que converge hacia una media a lo largo del tiempo. Mientras continúe mejorando el proceso de estimación, mejorará la precisión de su velocidad como predictor de la capacidad de Sprint. El valor de la velocidad está en su capacidad para predecir la capacidad a pesar de las perturbaciones y la periodicidad, por lo que casi nunca hay una buena razón para reconfigurar los resultados de un Sprint individual y, de hecho, ¡muchas razones para no hacerlo!

Los equipos ágiles deben ser lo suficientemente pequeños y los Scrum Sprints lo suficientemente cortos como para que no sea necesario un seguimiento formal de las desviaciones de la estimación de la planificación. Como estos datos nunca deben usarse fuera de un único cuadro de tiempo de Sprint, tampoco es necesario conservar estos datos más allá del cuadro de tiempo.

En resumen, vale la pena revisar las discrepancias en las estimaciones o identificar los impedimentos del proceso que impidieron que una historia se terminara al 100%. Sin embargo, rastrear estos datos como un elemento de primera clase en una tarjeta de historia es en gran medida un antipatrón.