Cinco métricas ágiles que no odiarás

Las estadísticas y los diagramas son herramientas potentes. Usadlas bien, queridos trabajadores ágiles... usadlas bien. 

Dan Radigan Dan Radigan

Las métricas son un tema complicado.

Por un lado, todos hemos estado en un proyecto en el que no se ha supervisado ningún tipo de dato, y era complicado decir si íbamos cumpliendo los objetivos para la publicación o si éramos más eficientes según avanzaba el proyecto. Por otro lado, muchos hemos tenido la mala suerte de participar en proyectos en los que las estadísticas se usaban como un arma, enfrentando a un equipo frente a otro o justificando el trabajo obligatorio del fin de semana. Así que no es ninguna sorpresa que la mayoría de los equipos tengan una relación de amor-odio con las métricas.

Sin embargo, no tiene que ser de este modo. Supervisar y compartir métricas ágiles sólidas puede reducir la confusión y arrojar luz sobre el progreso (y retrasos) del equipo a lo largo del ciclo de desarrollo. Te explicamos cómo a continuación.

Conoce tu trabajo

El estado "Done" (Finalizado) solo cuenta la mitad de la historia. Se trata de crear el producto correcto en el momento oportuno para el mercado adecuado. Para no desviarse del camino a lo largo del programa, es necesario recopilar y analizar algunos datos. En todos los programas ágiles, es importante realizar un seguimiento de las métricas empresariales y ágiles. Las métricas empresariales informan de la adecuación de la solución al mercado, mientras que las métricas ágiles miden aspectos del proceso de desarrollo.

Las métricas empresariales de un programa deben estar fundamentadas en su hoja de ruta.

Para cada iniciativa de la hoja de ruta, incluye varios indicadores clave del rendimiento (KPI) asociados a los objetivos del programa. Además, incluye criterios del éxito para cada requisito del producto, como la tasa de adopción por los usuarios finales o el porcentaje de código cubierto por pruebas automatizadas. Estos criterios de éxito alimentan las métricas ágiles del programa. Cuanto más aprendan los equipos, mejor se adaptarán y evolucionarán. 

Cómo usar métricas ágiles para optimizar la entrega

The agile metrics discussed below focus on the delivery of software. Whether you are a scrum or kanban team, each of these agile metrics will help the team better understand their development process, making releasing software easier.

Sprint burndown

Los equipos de scrum organizan el desarrollo en sprints con un tiempo asignado. Al inicio del sprint, el equipo plantea un pronóstico de la cantidad de trabajo que puede completar durante el sprint. Un informe de evolución de sprints supervisa la finalización del trabajo a lo largo del sprint. El eje de abscisas representa el tiempo y el eje de ordenadas se refiere a la cantidad de trabajo que queda por completar, medido en puntos de historia u horas. El objetivo es haber finalizado todo el trabajo previsto al final del sprint.

Un equipo que cumple permanentemente las previsiones es un indicador atractivo de metodología ágil en la organización. Sin embargo, no caigas en la tentación de alterar las cifras declarando la finalización de un elemento antes de que esté terminado de verdad. Puede parecer positivo a corto plazo, pero a largo plazo únicamente lastra el aprendizaje y la mejora.  

Antipatrones ante los que estar alerta
  • El equipo termina antes de tiempo todos los sprints porque no están asumiendo trabajo suficiente. 
  • El equipo no cumple las previsiones sprint tras sprint porque están asumiendo demasiado trabajo. 
  • La línea de evolución marca caídas pronunciadas en lugar de una evolución más gradual debido a que el trabajo no se ha dividido granularmente.
  • El propietario del producto añade o cambia el alcance en mitad del sprint.

Evolución de epics y publicaciones

Los diagramas de evolución de épicas y versiones sirven para realizar el seguimiento del progreso del desarrollo a lo largo de una muestra más amplia de trabajo que en la evolución de sprints, y guía el desarrollo de los equipos de scrum y kanban. Dado que un sprint (en los equipos de scrum) puede contener trabajo de varias épicas y versiones, es importante supervisar el progreso de los sprints individuales, así como de las épicas y las versiones.

La "corrupción del alcance" es la inyección de nuevos requisitos en un proyecto ya definido. Por ejemplo, si un equipo entrega un nuevo sitio web a la empresa, la corrupción del alcance pedirá nuevas funcionalidades después de que se haya realizado el esquema de los requisitos iniciales. Aunque tolerar la corrupción del alcance durante un sprint es mala práctica, los cambios en el alcance en las épicas y versiones son una consecuencia natural de un desarrollo ágil. A medida que el equipo avance por el proyecto, el propietario del producto puede decidir asumir o retirar trabajo en función del aprendizaje. Los diagramas de evolución de épicas y versiones informan a todo el mundo del flujo de trabajo dentro de la épica y la versión. 

Antipatrones ante los que estar alerta
  • Las previsiones de epics o versiones no se actualizan a medida que el equipo avanza por el trabajo.
  • No se observa progreso después de varias iteraciones. 
  • La corrupción del alcance crónica, que pueden indicar que el propietario del producto no entiende completamente el problema que esa parte del trabajo intenta solucionar.
  • El alcance aumenta con mayor rapidez que la capacidad de absorción del equipo.
  • El equipo no está lanzando versiones incrementales a lo largo del desarrollo de un epic.

Velocidad

La velocidad es la cantidad media de trabajo que un equipo de scrum lleva a cabo durante un sprint, medida en puntos de historia u horas, y es muy útil para los pronósticos. El propietario del producto puede usar la velocidad para predecir la rapidez con la que un equipo puede recorrer el backlog, debido a que el informe supervisa el trabajo previsto y el completado a lo largo de varias iteraciones. Cuantas más iteraciones se contemplen, más precisa será la previsión.

Digamos que el propietario del producto desea completar 500 puntos de historia del backlog. Sabemos que el equipo de desarrollo generalmente completa 50 puntos de historia en cada iteración. Es razonable que el propietario del producto suponga que el equipo necesitará 10 iteraciones (más o menos) para finalizar el trabajo requerido.

Es importante supervisar la evolución de la velocidad a lo largo del tiempo. Los nuevos equipos seguramente vean un aumento en velocidad a medida que el equipo optimice las relaciones y los procesos de trabajo. Los equipos existentes pueden supervisar su velocidad para garantizar un rendimiento coherente a lo largo del tiempo, y pueden confirmar si un cambio en un proceso concreto ha mejorado algo o no. Un descenso de la velocidad media generalmente es un indicador de que alguna parte del desarrollo del equipo se ha vuelto ineficiente y debería tratarse en la siguiente retrospectiva.

Antipatrones ante los que estar alerta

Si la velocidad experimenta muchas variaciones en un largo periodo de tiempo, revisa las prácticas de estimación del equipo. En la retrospectiva del equipo, pregunta lo siguiente:

  • ¿Hay dificultades de desarrollo que no tuvimos en cuenta al estimar el trabajo? ¿Cómo podemos dividir mejor el trabajo para detectar algunas de estas dificultades?
  • ¿Hay presión empresarial externa que empuja al equipo más allá de sus límites? ¿Se están sacrificando las buenas prácticas de desarrollo debido a ello?
  • Como equipo, ¿somos demasiado optimistas al realizar previsiones de los sprints? 

Each team’s velocity is unique. If team A has a velocity of 50 and team B has a velocity of 75, it doesn't mean that team B has higher throughput. Since each team's estimation culture is unique, their velocity will be as well. Resist the temptation to compare velocity across teams. Measure the level of effort and output of work based on each team's unique interpretation of story points. 

Gráfico de control

Control charts focus on the cycle time of individual issues–the total time from "in progress" to "done". Teams with shorter cycle times are likely to have higher throughput, and teams with consistent cycle times across many issues are more predictable in delivering work. While cycle time is a primary metric for kanban teams, scrum teams can benefit from optimized cycle time as well.

Medir la duración del ciclo es un modo flexible y eficiente de mejorar los procesos de un equipo porque los resultados de los cambios se detectan casi instantáneamente, de modo que se permiten ajustes inmediatos. El objetivo final es tener una duración del ciclo corta y homogénea, independientemente del tipo de trabajo (nueva funcionalidad, deuda técnica, etc.).

Antipatrones ante los que estar alerta

Los gráficos de control pueden parecer demasiado variables al principio. No te preocupes demasiado con cada dato que se salga de la norma. Busca tendencias. Estas son dos áreas a las que estar atentos:

  • Aumento de la duración del ciclo: El aumento de la duración del ciclo mina la agilidad lograda con tanto esfuerzo por parte del equipo. En la retrospectiva del equipo, dedica tiempo a entender el motivo de este aumento. Una excepción: Si la definición que hace el equipo de "finalizado" ha aumentado, la duración del ciclo probablemente aumente también.
  • Duración del ciclo heterogénea: El objetivo es tener una duración del ciclo homogénea de los elementos de trabajo que tengan valores de punto de historia similares. Filtra el gráfico de control para cada valor de punto de historia en busca de homogeneidad. Si la duración del ciclo es heterogénea en valores de punto de historia grandes y pequeños, dedica tiempo en la retrospectiva a examinar los aspectos que se han pasado por alto y a mejorar las estimaciones futuras. 

Diagrama de flujo acumulado

El diagrama de flujo acumulado es un recurso clave para los equipos de kanban. Les ayuda a garantizar la coherencia del ritmo de trabajo en todo el equipo. Con el número de tiques en el eje de ordenadas, el tiempo en el eje de abscisas y colores para indicar los distintos estados del workflow, indica visualmente las limitaciones y los cuellos de botella conjuntamente con los límites del trabajo en curso.

El diagrama de flujo acumulado debería ser una curva suave de izquierda a derecha. Las burbujas o huecos en cualquier color indican limitaciones y cuellos de botella. Cuando veas uno de estos casos, busca maneras de suavizar las bandas de color en todo el diagrama.

Antipatrones ante los que estar alerta
  • Las incidencias que causan bloqueos crean enormes copias de seguridad en algunas partes del proceso y muy escasas en otros.
  • Crecimiento incontrolado del backlog a lo largo del tiempo. Esto da como resultado que los propietarios del producto no cierren incidencias obsoletas o que las incidencias con prioridad más baja no se traten nunca. 

Aún más métricas

Las buenas métricas no están limitadas a los informes mencionados anteriormente. Por ejemplo, la calidad es una métrica importante para los equipos ágiles y hay varias métricas tradicionales que pueden aplicarse al desarrollo ágil:

  • ¿Cuántos defectos se encuentran...
    • durante el desarrollo?
    • después de la publicación al cliente?
    • por personas ajenas al equipo?
  • ¿Cuántos defectos se aplazan para una versión futura?
  • ¿Cuántas solicitudes de servicio al cliente están llegando?
  • ¿Cuál es el porcentaje de cobertura de las pruebas automatizadas?

Los equipos ágiles también deben tener en cuenta la frecuencia de las publicaciones y la velocidad de entrega. Al final de cada sprint, el equipo debe publicar software a producción. ¿Con qué frecuencia ocurre eso? ¿Se están lanzando la mayoría de las compilaciones de versiones? En esta línea, ¿cuánto tarda el equipo en publicar una corrección urgente a producción? ¿La publicación es fácil para el equipo o requiere actuaciones heroicas?

Las métricas son solo una parte para crear la cultura de equipo. Aportan un análisis cuantitativo del rendimiento del equipo y proporcionan objetivos mensurables. Aunque son importantes, tampoco te obsesiones con ellas. Escuchar el feedback durante las retrospectivas es igual de importante para aumentar la confianza del equipo, la calidad del producto y la velocidad de desarrollo en todo el proceso de publicación. Usa feedback cuantitativo y cualitativo para impulsar los cambios. 

Up Next
Advantage