Cinco métricas KPI ágiles que no odiarás
Las estadísticas y los gráficos son herramientas muy útiles. Usadlas bien, queridos equipos de metodología ágil… usadlas bien.
Obtén la plantilla gratuita de informe de proyecto
Agiliza la elaboración de informes de tus proyectos con informes coherentes y completos para obtener una visión general íntegra de tus proyectos.
PRINCIPALES CONCLUSIONES
Las métricas ágiles, como el trabajo pendiente de los sprints, la velocidad, la duración del ciclo y los diagramas de flujo acumulativo, ayudan a los equipos a realizar un seguimiento del progreso y optimizar la entrega.
Estas métricas proporcionan información sobre el rendimiento del equipo, los cuellos de botella y las previsiones para futuros sprints.
La revisión periódica de las métricas contribuye a la mejora continua y a la toma de decisiones basada en los datos.
Incorpora métricas ágiles en las retrospectivas para identificar tendencias y perfeccionar el flujo de trabajo de tu equipo a fin de obtener mejores resultados.
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 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.
¿Qué son las métricas de la metodología ágil?
Las métricas ágiles son medidas cuantitativas que se utilizan para hacer un seguimiento del progreso, la calidad y la eficacia de los equipos y proyectos de metodología ágil. Entre las métricas más comunes se incluye la velocidad, el plazo de entrega, la duración del ciclo, los gráficos de trabajo pendiente y los diagramas de flujo acumulado.
Estas métricas ayudan a los equipos a identificar los cuellos de botella, prever las entregas e impulsar la mejora continua. Por ejemplo, la supervisión de la velocidad permite a los equipos predecir cuánto trabajo pueden finalizar en futuros sprints, mientras que el control de la duración del ciclo saca a relucir las áreas de optimización de los procesos.
¿Qué es un KPI en el contexto de las metodologías ágiles?
En el contexto de las metodologías ágiles, un KPI (indicador clave de rendimiento) es una métrica específica que se usa para cuantificar el éxito de un equipo o proyecto en comparación con las metas fijadas. Entre los KPI se pueden incluir la satisfacción del cliente, el índice de defectos o el plazo de comercialización, según lo que la organización considere más importante. El hecho de seleccionar los KPI adecuados garantiza que los equipos se centren en aportar valor y alcanzar los objetivos estratégicos. Por ejemplo, un equipo podría llevar un control de la cantidad de errores críticos resueltos por sprint y considerarlo un KPI para mejorar la calidad del producto y la experiencia del cliente.
Cómo usar métricas KPI ágiles para optimizar la entrega
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 datos relevantes 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 estar fundamentadas 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 incluido en 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.
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. 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 la 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á 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.
Trabajo pendiente de epics y publicaciones
Los diagramas de trabajo pendiente de epics y versiones sirven para realizar el seguimiento del progreso del desarrollo a lo largo de una muestra más amplia de trabajo que en el diagrama de trabajo pendiente 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 varios epics y versiones, es importante supervisar el progreso de los sprints individuales, 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, un ejemplo de corrupción del alcance sería pedir nuevas funciones después de que se haya realizado el esquema de los requisitos iniciales. Aunque tolerar la corrupción del alcance durante un sprint es una mala práctica, los cambios en el alcance en los epics y las 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 gráficos de trabajo pendiente de los epics y las versiones informan a todo el mundo del flujo de trabajo dentro del epic y de 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?
La velocidad de cada equipo es única. Si el equipo A tiene una velocidad de 50 y el equipo B tiene una velocidad de 75, 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 varios equipos. Mide el nivel 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 el tiempo del ciclo de las incidencias individuales, es decir, el tiempo total para pasar de "en curso" a "finalizado". Los equipos con duraciones del ciclo más cortas seguramente tengan mayor rendimiento, y los equipos con duraciones del ciclo homogéneas en numerosas incidencias son más predecibles. Si bien la duración del ciclo es una métrica fundamental para los equipos de kanban, los equipos de scrum también pueden sacar partido una duración del ciclo optimizada.
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 metodología ágil lograda con tanto esfuerzo por parte del equipo. En la retrospectiva del equipo, dedica tiempo a entender el motivo de este aumento. Existe 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 para comprobar la 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 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 es el resultado de que los propietarios del producto no cierren incidencias obsoletas o de que las incidencias con prioridad más baja no se aborden nunca.
Más métricas ágiles
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?
Consulta información útil en su contexto
Con la información útil, los equipos pueden acceder a métricas cuando las necesitan: durante la planificación de sprints, en la reunión rápida diaria o cuando quieren optimizar las entregas. Puedes consultar la información útil en la esquina superior derecha de las vistas de tablero, backlog e implementaciones de Jira.
La información útil proporciona una instantánea visual de las siguientes métricas:
Progreso del sprint
Desglose de tipos de incidencias
Compromiso con el sprint
Frecuencia de implementación
Duración del ciclo
Utiliza estas métricas para optimizar continuamente el rendimiento del equipo. Descubre más detalles sobre la información útil.
¿Cómo se mide el éxito de un proyecto ágil?
El éxito de un proyecto ágil se mide evaluando tanto las métricas cuantitativas como los resultados cualitativos, como la entrega de valor a los clientes, el cumplimiento de los objetivos empresariales y el fomento de la colaboración en equipo. Los indicadores clave son la entrega puntual, la satisfacción de las partes interesadas y la capacidad de adaptarse al cambio. Los equipos suelen utilizar una combinación de métricas como la velocidad, los comentarios de los clientes y el impacto empresarial para evaluar el rendimiento. Por ejemplo, un proyecto que ofrece un producto de alta calidad dentro del plazo previsto y recibe comentarios positivos de los usuarios se consideraría un éxito en un contexto ágil.
Conclusión
Las métricas y los KPI de metodología ágil son solo una parte de los elementos necesarios 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 la opinión del equipo durante las retrospectivas es igual de importante para aumentar su confianza, 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.
Recomendado para ti
Plantillas
Plantillas de Jira listas para usar
Echa un vistazo a nuestra biblioteca de plantillas personalizadas de Jira para varios equipos, departamentos y flujos de trabajo.
Guía del producto
Una introducción completa a Jira
Usa esta guía paso a paso para descubrir las funciones esenciales y las prácticas recomendadas para maximizar tu productividad.
Guía de Git
Los conceptos básicos de Git
Tanto si eres principiante como si ya tienes nivel de experto, usa esta guía de Git para aprender los conceptos básicos con tutoriales y consejos útiles.