Autor: Jordi Salvat i Alabart

(Esta es la traducción al castellano de mi blogpost http://jordionsoftware.blogspot.com/2009/10/simple-metrics-for-scrum.html)

---

 

Al terminar mi charla en la Barcelona PHP Conference recibí varias preguntas sobre las métricas que utilizamos: como construimos nuestros gráficos de burn-down, etc.

Esto es lo que estamos haciendo a día de hoy. Es una mezcla de ideas de "Scrum and XP from the Trenches", "Agile Estimation and Planning" [1], y las nuestras propias:

 

• El Product Backlog (PBL) se estima en Story Points sin dimensión utilizando Planning Poker. Para ello hacemos por lo menos una sesión de planning poker en cada sprint. Estas estimaciones solo se usan para la planificación a largo plazo[2].
• Antes de cada reunión de planificación de Sprint, calculamos de cuantas horas·hombre disponemos en el siguiente sprint. Después multiplicamos por un factor de foco (actualmente 55%). Hasta hace un par de sprints, utilizábamos el factor obtenido en el sprint anterior, pero eso no funcionaba bien y causaba sprints alternados de carga demasiado grande/demasiado ligera. Así que decidimos fijar un valor en la parte baja del rango y subirlo lentamente cuando tengamos confianza en que podemos hacerlo. Creo que aún no hemos terminado de experimentar en este área.
• En cada reunión de planificación de sprint, seleccionamos (el equipo y el Product Owner) unos pocos ítems del principio del PBL, identificamos sus tareas (en post-its amarillos), y estimamos cada una en horas (horas ideales, para ser preciso). Decidimos qué (y cuantos) ítems incluir en base a estas horas: el total no debe exceder el producto calculado en el paso anterior. Los post-its para los ítems elegidos van a la columna "Pendiente" en el tablero de tareas.
• La suma de las estimaciones de las tareas seleccionadas es el primer punto del gráfico de burn-down.
• El equipo actualiza cada día el tablero de tareas como sigue:
  • Escribiendo dos números en cada una de las tareas en las que han trabajado: horas trabajadas en ella desde el sprint previo y horas estimadas que quedan para completarla.
  • Moviendo cada tarea completada a la columna “completada”.
  • Añadiendo un post-it azul por cada tarea que ha sido adicionada “con disposición” en el sprint. Por supuesto, sólo hacemos esto cuando estamos claramente avanzados respecto al plan (“con disposición” significando que tenemos la elección de cogerla o no, en contraste con el “forzada” que indico más abajo).
  • Añadiendo un post-it rojo (con una estimación) en la fila superior (etiquetada “fuera de sprint”) para cada tarea no planeada que ha sido "forzada" a ser introducida en el sprint. Preferiríamos evitar esto, pero el negocio necesita que cojamos algunas de ellas (son mayoritariamente tareas de valor añadido que no pueden ser planeadas por que dependen de eventos externos como ventas de campañas de publicidad). Los errores en producción también son tratados de esta manera.
  • También ponemos con un post-it rojo las tareas que deberían formar parte del sprint pero que no fuimos capaces de identificar durante la planificación, sólo que van en la fila correspondiente a su ítem de producto.
• Después sumo la última estimación disponible para cada tarea en la parte "viva" del tablero de tareas (eso es: todas las tareas salvo las completadas) para obtener una estimación del trabajo que falta. Ese es el valor que pongo cada día en el gráfico de burn-down. La suma manual es engorrosa, pero solo me toma un par de minutos, que contribuyo contento a cambio de las muchas ventajas de usar un tablero de tareas de verdad y no una herramienta electrónica.
• Al final de cada sprint produzco un pequeño conjunto de estadísticas que publico en la página wiki de ese sprint (indicando al lado de cada una el valor del sprint anterior para poder comparar, aunque sería mejor usar gráficos):

 

ESTADÍSTICAS INICIALES (calculadas al principio del sprint)

A. Velocidad objetivo: suma de los "story points" de todos los items del PBL inicialmente incluídos en el sprint.
B. Horas estimadas: suma de las estimaciones en todos los post-its amarillos al principio del sprint. Como he dicho antes, este es el primer valor que dibujo en el gráfico de burn-down.
C. Horas diponibles: total de horas·hombre disponibles para el sprint.
D. Factor de foco objetivo (B/C): como un %

 

ESTADÍSTICAS FINALES (calculadas al terminar el sprint)

E. Velocidad real: suma de los "story points" realmente completados en el sprint

F. Horas reales: número real de horas dedicadas al sprint (eso es: C – bajas médicas y similares + horas extras si las hubiera)
G.Total estimaciones tareas previstas en sprint completadas: suma de las estimaciones iniciales de los post-its amarillos y azules que realmente completamos. Eso es: B + post-its azules – trabajo excluído del sprint.
H. Factor de foco (G/F): como un %

J. Horas cargadas a tareas planeadas: recuento de todas las horas reportadas en todos los post-its amarillos y azules completados en el sprint. Este es el más pesado de calcular, pero no son más de dos o tres minutos por sprint, así que deja de gimotear. Incluso mi hija de 9 años puede sumar eso sin necesidad de un ordenador.
K. Horas cargadas a tareas no planificadas "dentro del sprint"
L. Error de estimación ((J+K)/G-1): como un %
M. Factor de foco real ((J+K)/F): como un %

N. Horas cargadas a tareas no planificadas "fuera de sprint": con frecuencia las descompongo en categorías tales como bugfixes, soporte, operaciones, publicidad,…

P. Total de horas cargadas (J+K+N)
Q. Error de reportado (1-P/F)

 

Son un montón de valores, y la nomenclatura de los varios "factores de foco" puede ser confusa, pero nos permiten dilucidar, cuando hay problemas de planificación, si fue por un exceso de trabajo no planificado, estimación inválida (hubo tareas que no supimos identificar), o estimación imprecisa. Los dos últimos valores (P y Q) son solo un "checksum" para alertarnos si nos ponemos vagos y dejamos de reportar las horas adecuadamente.

 

Para saber más

• [1] Otros recursos sobre Scrum
• [2] Introducción a la estimación y planificación ágil
• Métricas ágiles y cuadro de mandos integral para Scrum
• Métricas ágiles y valor – VI encuentro ágil en Barcelona

 

 

• métricas