3 informes ágiles de burndown y cómo usarlos

Las prácticas ágiles, para los no iniciados y mal informados, a veces pueden aparecer como metodologías ad hoc de desarrollo de software y gestión de proyectos. La verdad es muy diferente.

Uno de los 12 principios del software ágil establece: “Las mejores arquitecturas, requisitos y diseño surgen de equipos autoorganizados”, pero la mayoría de las organizaciones que aplican prácticas ágiles, incluidos scrum y Kanban, imponen algunos rigores y rituales de proceso importantes. Por ejemplo, muchas organizaciones implementan prácticas de planificación ágiles que incluyen estimación de puntos de historia, estándares de arquitectura y disciplinas de gestión de versiones para mejorar el impacto comercial, la calidad y la fiabilidad de las versiones de aplicaciones.

La mayoría de los equipos optan por utilizar una herramienta ágil como Jira Software o Azure DevOps para administrar los trabajos pendientes, los sprints y la colaboración entre equipos ágiles. El objetivo principal de estas herramientas es gestionar de forma centralizada los requisitos, el estado del sprint, el flujo de trabajo y la colaboración entre los miembros del equipo ágil y varios equipos ágiles. Sin embargo, cuanto más riguroso pongan las organizaciones en el uso de estas herramientas, más estas herramientas pueden ayudar a los líderes y equipos a identificar problemas, informar a las partes interesadas sobre el estado y mejorar su ejecución.

Uno de los informes listos para usar más comunes es el informe de evolución. Dado que las prácticas ágiles permiten a los propietarios de productos volver a priorizar el trabajo pendiente en función de los comentarios de los clientes, los informes tradicionales como los diagramas de Gantt no logran capturar la naturaleza fluida de la ejecución ágil. Para el gráfico de evolución es fundamental que tenga en cuenta el trabajo completado, el trabajo nuevo agregado al alcance y otros cambios de alcance. El gráfico de evolución puede proporcionar una imagen rápida de cómo los equipos avanzan hacia sus metas.

Leer un gráfico de evolución de sprint básico

Los gráficos de evolución suelen tener tiempo en el eje xy estimaciones en el eje y. Muchos equipos estiman en puntos de historia, pero muchas herramientas ágiles pueden trazar quemaduras por el número de historias o estimaciones en horas. Para este artículo, asumiré que se están utilizando puntos de la historia.

El informe de evolución del sprint traza el número de puntos de la historia que están dentro del alcance del intervalo de tiempo. A medida que el equipo completa las historias, el gráfico muestra cómo están "quemando" la lista de historias y otros tipos de trabajo (problemas en Jira, tipos de elementos de trabajo en Azure DevOps) hasta que se completa el trabajo o finaliza el sprint. Cuando los equipos completan el trabajo comprometido con el sprint, la línea trazada se cruza con el eje x, lo que indica que todo está hecho.

El sprint burndown es el más fácil de conceptualizar. En el primer día del sprint, el equipo se compromete con algunas historias y el número total de puntos de la historia. Si revisa el gráfico de evolución ese día, debería ver un solo punto en el eje y que representa la cantidad de puntos que el equipo se comprometió en el día cero del sprint.

A medida que las historias se marcan como completadas, el sprint burndown muestra el número restante de puntos para completar.

¿Cómo se usa un sprint burndown en la práctica? Un quemado saludable muestra una curva lineal e idealmente exponencial hasta cero. Si la curva tiene una pendiente plana en la primera parte de un sprint, puede indicar bloqueos o mucho trabajo en progreso y que el sprint puede estar en riesgo. Un quemado plano o de pendiente lenta puede ser muy problemático si se realizan muchas pruebas en historias con código completo y si el trabajo de prueba no puede comenzar hasta los últimos días del sprint.  

Una burndown de sprint que desciende rápidamente es generalmente algo bueno, pero puede indicar que el equipo no se está comprometiendo o solo ha elegido asumir historias más pequeñas en el sprint.

Los avances épicos rastrean el progreso en comparación con los impulsores comerciales y técnicos

Los avances de Sprint son muy útiles para rastrear la ejecución a corto plazo y ayudan a los equipos a cumplir con éxito los compromisos de Sprint. Para realizar un mejor seguimiento del progreso con respecto a los objetivos a más largo plazo, las cargas épicas y de lanzamiento brindan la visibilidad necesaria.

Las cargas épicas funcionan mejor cuando los equipos definen varios esfuerzos de larga duración, como la implementación de las principales capacidades del usuario final, las estrategias de deuda técnica, las mejoras de rendimiento o la evolución de los procesos. Para aprovechar las épicas burndowns, la acumulación debe tener:

  • Entre cinco y 15 épicas que durarán al menos varios meses y tomarán seis o más sprints para completar.
  • Características, historias y resúmenes de historias que se acumulan debajo de la épica y representan un plan de alto nivel para ejecutar en la épica.
  • Estimaciones de alto nivel, idealmente en puntos de historia para cada historia o talón de historia que se acumula debajo de las epopeyas.

Una vez que estos están en su lugar, la evolución épica traza los cambios en este plan. Su eje x representa los sprints y el eje y representa la estimación total de historias y resúmenes de historias asignados a la epopeya. En el gráfico de evolución épico de Jira Software, verá un gráfico de barras con un color que representa las historias completadas en el sprint y un segundo que muestra los puntos de la historia agregados. Los puntos de historia aumentan cuando se agregan nuevas historias o talones de historias a la épica o cuando cambian las estimaciones.

Hay varias formas de utilizar la tabla de evolución épica:

  • Ilustra la velocidad de completar características e historias contra el plan. Cuando los planes son precisos y la velocidad del equipo es constante, puede proporcionar un indicador cuando se completa el trabajo épico.
  • La mayoría de los planes ágiles no están completos y los equipos agregan, cambian y eliminan historias en función de los comentarios del usuario final, el descubrimiento de complejidades técnicas y para abordar la deuda técnica introducida durante el viaje. El quemado épico luego indica qué tan lejos del plan está la epopeya en función de cuánto está creciendo la acumulación en comparación con la finalización sprint a sprint.
  • Los burndowns épicos también ayudan a comparar los esfuerzos en múltiples sprints y a medir cuánto trabajo de planificación y entrega se realiza en una épica frente a otras.

Las burndowns de lanzamientos informan a los equipos si los lanzamientos alcanzarán la fecha y el alcance

Es posible que los equipos avanzados que automatizan por completo sus procesos de entrega con integración continua, pruebas continuas y entrega continua no necesiten demoras de lanzamiento. Los equipos que implementan con frecuencia deben rastrear qué características e historias están vinculadas a la versión, pero la evolución de la versión no es muy útil, ya que a menudo rastrea el progreso por sprint.

Para otros equipos que siguen las prácticas de administración de versiones y estandarizan las versiones de múltiples impresiones, el burndown de versiones puede ser la herramienta más importante del propietario del producto y del equipo.

El quemado del lanzamiento es similar al quemado épico, excepto que en lugar de rastrear características, historias y resguardos de historias asignados a una épica, el quemado del lanzamiento muestra lo que está asignado a un lanzamiento. El eje y las barras son idénticos a las épicas quemaduras.

Por lo tanto, los equipos que utilizan burndowns de versiones pueden realizar un seguimiento del alcance y el cronograma de una versión. Los equipos que están en la pista verán una pendiente de combustión hacia el eje x con una pendiente consistente con la velocidad del equipo. Los lanzamientos que pueden desviarse del camino tienen una pendiente más pequeña o representan más puntos de historia que se agregan (cuando se agrega más alcance al lanzamiento) que lo que se está completando.

Jira Software le ayuda con estas proyecciones. Suponiendo que el equipo ha estado trabajando en el proyecto durante al menos tres sprints, Jira Software calculará una velocidad promedio del equipo y predecirá el sprint final para un lanzamiento basado en esta velocidad.

Los sprints, épicos y lanzamientos le dan a los equipos algunas herramientas fáciles de usar para alinearse con los objetivos. Cuando los equipos tienen una comprensión compartida del alcance, acuerdan las prioridades, planifican varios sprints con anticipación y etiquetan las historias en su cartera de trabajos de manera adecuada, los burndowns cuentan la historia de si la planificación y la ejecución están alineadas con los objetivos. Cuando no lo son, son una herramienta basada en datos que puede impulsar la discusión sobre qué ajustes pueden ser necesarios.