Cinco métricas ágiles que no odiarás

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

Dan Radigan Dan Radigan
Browse topics

Las métricas son un tema delicado.

Por un lado, todos hemos estado en algún proyecto en el que no se ha hecho un seguimiento de ningún tipo de dato, y en el que costaba distinguir 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 arma arrojadiza para enfrentar a un equipo contra otro o para justificar el trabajo obligatorio durante el fin de semana. Por lo tanto, 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 por qué ser así. Hacer un seguimiento de métricas ágiles sólidas y compartirlas puede reducir la confusión y arrojar luz sobre el progreso (y los retrasos) del equipo a lo largo del ciclo de desarrollo. A continuación te explicamos cómo.

Conoce tu trabajo

El estado "Finalizado" solo cuenta la mitad de la historia. Se trata de crear el producto correcto, en el momento oportuno y para el mercado adecuado. Para no desviarse del camino a lo largo del programa, hay que recopilar y analizar algunos datos durante el proceso. En todos los programas ágiles, es importante hacer un seguimiento tanto de las métricas empresariales como de las á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 basarse en su hoja de ruta.

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

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

Las métricas ágiles mencionadas a continuación se centran en la entrega de software. Tanto si usas scrum como kanban, todas estas métricas ágiles ayudarán al equipo a entender mejor su proceso de desarrollo y a simplificar la publicación de software.

Trabajo pendiente de los sprints

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. Acto seguido, mediante un informe de trabajo pendiente del sprint, se hace un seguimiento del trabajo realizado a lo largo del sprint. El eje de abscisas representa el tiempo y, el eje de ordenadas, la cantidad de trabajo que queda por terminar, medido en puntos de historia o en horas. El objetivo es tener acabado todo el trabajo previsto al final del sprint.

Un equipo que cumple constantemente 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 que un elemento está terminado antes de que lo esté en realidad. Puede parecer algo positivo a corto plazo, pero, a la larga, solo lastrará el aprendizaje y la mejora. 

Antipatrones ante los que estar alerta
  • El equipo termina antes de tiempo todos los sprints porque no está asumiendo la cantidad de trabajo que debería. 
  • El equipo no cumple las previsiones sprint tras sprint porque está asumiendo demasiado trabajo. 
  • La línea del trabajo pendiente presenta caídas abruptas en lugar de una evolución más gradual porque el trabajo no se ha dividido en fragmentos granulares.
  • El propietario del producto añade o cambia el alcance del sprint con el sprint ya comenzado.

Trabajo pendiente de epics y publicaciones

Las gráficas de trabajo pendiente del epic y la publicación (o la versión) sirven para hacer un seguimiento del progreso del desarrollo a lo largo de una muestra más amplia de trabajo que las gráficas de trabajo pendiente de los sprints, y guían el desarrollo de los equipos de scrum y kanban. Dado que un sprint (en los equipos de scrum) puede contener trabajo de varios epics y versiones, es importante hacer un seguimiento del progreso de cada uno de los sprints, así como de los epics 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 funciones después de que se hayan esbozado los requisitos iniciales. Si bien tolerar la corrupción del alcance durante un sprint es una mala práctica, cambiar el alcance en los epics y las versiones resulta una consecuencia natural del desarrollo ágil. A medida que el equipo avanza en el proyecto, el propietario del producto puede optar por asumir o retirar trabajo en función del aprendizaje. Las gráficas de trabajo pendiente de epics y versiones informan a todo el mundo de las fluctuaciones de trabajo dentro del epic y la versión. 

Antipatrones ante los que estar alerta
  • Los pronósticos de los epics o de las versiones no se actualizan a medida que el equipo avanza en el trabajo.
  • No se avanza en el transcurso de varias iteraciones. 
  • Corrupción crónica del alcance, que puede ser una señal de que el propietario del producto no entiende completamente el problema que trata de resolver ese conjunto de trabajo.
  • El alcance crece a un ritmo más rápido del que el equipo puede asumir.
  • El equipo no lanza publicaciones graduales durante el 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 resulta muy útil para los pronósticos. El propietario del producto puede usar la velocidad para predecir la rapidez con la que un equipo puede hacerse cargo de los elementos del backlog, ya que el informe hace un seguimiento del trabajo previsto y el terminado a lo largo de varias iteraciones (cuantas más iteraciones se contemplen, más precisa será la previsión).

Pongamos que el propietario del producto desea completar 500 puntos de historia del backlog. Sabemos que el equipo de desarrollo suele completar 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 hacer un seguimiento de la evolución de la velocidad a lo largo del tiempo. Los nuevos equipos pueden prever un aumento en la velocidad a medida que el equipo optimiza las relaciones y los procesos de trabajo. Los equipos existentes pueden hacer un seguimiento de su velocidad para garantizar un rendimiento constante a lo largo del tiempo, así como para confirmar si un cambio en un proceso concreto ha mejorado algo o no. Un descenso de la velocidad media suele constituir un indicio de que algún componente del proceso de desarrollo del equipo se ha vuelto ineficiente y debería tratarse en la siguiente retrospectiva.

Antipatrones ante los que estar alerta

Siempre que la velocidad sea errática durante un periodo prolongado, deberás revisar las prácticas de estimación del equipo. Durante la retrospectiva del equipo, plantea las siguientes preguntas:

  • ¿Existen problemas de desarrollo imprevistos que no tuvimos en cuenta al estimar este trabajo? ¿Cómo podemos desglosar mejor el trabajo para detectar algunos de estos problemas?
  • ¿Existe alguna presión empresarial externa que obligue al equipo a forzar sus límites? ¿Se ve perjudicada por consiguiente la adhesión a las prácticas recomendadas de desarrollo?
  • Como equipo, ¿somos demasiado entusiastas a la hora de pronosticar el sprint? 

La velocidad de cada equipo es única. Si el equipo A tiene una velocidad de 50 y, el equipo B, de 75, eso no significa que el rendimiento de B sea mayor. Dado que la cultura de estimación de cada equipo es única, su velocidad también lo será. No caigas en la tentación de comparar la velocidad de los diferentes equipos. Debes medir el grado de esfuerzo y los resultados del trabajo en función de la interpretación única que cada equipo hace de los puntos de historia. 

Gráfico de control

Los gráficos de control se centran en la duración del ciclo de cada incidencia, es decir, en el tiempo total para pasar del estado "en curso" a "finalizado". Los equipos con ciclos de menor duración probablemente presentarán un rendimiento mayor, mientras que los equipos con ciclos de una duración consistente en numerosas incidencias resultan más predecibles a la hora de entregar el trabajo. La duración del ciclo es una métrica fundamental para los equipos de kanban; sin embargo, los equipos de scrum también pueden obtener ventajas si consiguen optimizar la duración del ciclo.

Medir la duración del ciclo supone una forma flexible y eficiente de mejorar los procesos de un equipo, ya que los resultados de los cambios se detectan casi instantáneamente, lo cual permite efectuar cualquier ajuste de inmediato. El objetivo final es tener una duración del ciclo corta y consistente, independientemente del tipo de trabajo (nueva función, deuda técnica, etc.).

Antipatrones ante los que estar alerta

Los gráficos de control de calidad pueden parecer poco constantes al principio. No te preocupes demasiado por lo atípico: busca tendencias. Estos son dos aspectos a los que debes prestar atención:

  • Prolongación de la duración del ciclo: el aumento de la duración del ciclo va mermando en el equipo la agilidad que tanto le ha costado conseguir. En la retrospectiva del equipo, deberás dedicar tiempo para entender estos aumentos. Excepción: si se ha ampliado la definición de "finalizado" que tiene el equipo, es probable que la duración del ciclo también lo haga.
  • Duración errática del ciclo: el objetivo es contar con una duración del ciclo constante para los elementos de trabajo con valores de puntos de historia parecidos. Debes filtrar el gráfico de control de cada valor de punto de historia para comprobar su consistencia. Si la duración del ciclo es errática en tanto los valores de puntos de historia reducidos como en los grandes, deberás dedicar tiempo en la retrospectiva a examinar los fallos y a mejorar la estimación futura. 

Diagrama de flujo acumulado

El diagrama de flujo acumulado es un recurso esencial para los equipos de kanban. Les ayuda a garantizar la consistencia del flujo de trabajo en todo el equipo. Con el número de incidencias en el eje de ordenadas, el tiempo en el eje de abscisas y colores para indicar los distintos estados del flujo de trabajo, indica visualmente las limitaciones y los cuellos de botella, y funciona de forma conjunta 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 acumulaciones en algunas partes del proceso y escasez en otras.
  • Crecimiento desmedido del backlog con el tiempo. Esto se debe a que los propietarios de los productos no cierran las incidencias que están obsoletas o que, simplemente, tienen una prioridad demasiado baja como para empezar a trabajar en ellas. 

Métricas adicionales

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 detectan...
    • ... durante el desarrollo?
    • ... después de la publicación para los clientes?
    • ... a través de personas ajenas al equipo?
  • ¿Cuántos defectos se posponen para una publicación futura?
  • ¿Cuántas solicitudes de soporte 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 para producción. ¿Con qué frecuencia ocurre eso realmente? ¿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 para producción? ¿Le resulta fácil al equipo publicar o requiere actuaciones heroicas?

Las métricas son solo uno de los ingredientes para crear una 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 lo que tenga que decirte el equipo durante las retrospectivas resulta igual de importante para aumentar la confianza en todo el equipo, la calidad del producto y la velocidad de desarrollo en todo el proceso de publicación. Usa comentarios cuantitativos y cualitativos para impulsar los cambios. 

A continuación
Gantt Chart