17 métricas ágiles importantes que su equipo debería considerar

Las métricas han sido durante mucho tiempo un punto de debate entre los agilistas.

A pesar del hecho de que el desarrollo ágil es empírico debido a la entrega continua de software de calidad, las oficinas de PMO, los gerentes de proyecto y los clientes aún exigen informes de estado detallados como lo harían con cualquier proyecto basado en cascada. Si bien la necesidad comercial es una razón para la supervisión, el desarrollo ágil en sí mismo contribuye a un nivel de incertidumbre que algunas personas siempre quieren resolver.

En un esfuerzo por contrarrestar esta tendencia, muchos agilistas sostienen que las mediciones no deben usarse en absoluto y que solo la producción de software en sí debe considerarse el criterio para el éxito. Los defensores de este enfoque sostienen que los equipos de desarrollo y los gerentes de proyecto jugarán instintivamente con el sistema al manipular las historias de los usuarios y las estimaciones de tal manera que produzcan la apariencia de una alta eficiencia y oculten los problemas reales. Sin embargo, hay un adagio que dice que lo que se mide, se hace.

La razón principal por la que ocurre este juego es que las organizaciones confían demasiado en una o dos métricas en lugar de tener una solución de métrica integral. En este artículo, analizaremos las métricas que han demostrado producir la mejor inteligencia disponible sobre el rendimiento, la calidad, el valor e incluso la agilidad del equipo. Incluso hablaremos sobre algunas métricas de las que quizás nunca haya oído hablar, según las últimas investigaciones y los estudios de casos más innovadores.

¿Para qué se utilizan las métricas ágiles?

Las métricas ágiles se utilizan para realizar un seguimiento del estado, la calidad, la productividad, la eficiencia, el valor e incluso la agilidad misma. Lo que es más importante, se utilizan para informar las decisiones comerciales. Independientemente del tipo de proyecto en el que esté trabajando, los informes siempre serán importantes para las partes interesadas internas y externas. Las métricas pueden afectar las decisiones en todos los niveles, desde la gestión de productos hasta la gestión de personal y, como tales, deben ser precisas, informativas e imparciales. Antes de sumergirnos en las métricas, primero debemos establecer una base en la que se basen todas esas mediciones.

El Triángulo de Hierro vs. Triángulo Ágil

En los enfoques basados ​​en planes, las mediciones se basaban en el antiguo “triángulo de hierro” de alcance, cronograma y costo. La mayoría de las métricas caían en una de estas tres categorías. En el mundo ágil, este triángulo se ha invertido. Los proyectos se definen por la entrega de valor y calidad dentro de ciertas limitaciones. El presupuesto o el costo es simplemente una de estas restricciones, entre otras, en lugar de ser un enfoque principal para la entrega.

Es importante aquí entender la relación entre valor y calidad. Muchas personas luchan con la definición de valor. Primero, hay dos tipos de calidad: intrínseca y extrínseca.

• La calidad intrínseca se relaciona con la percepción interna del producto por parte de los equipos de desarrollo, pruebas y administración. Por lo general, se ilustra con métricas de defectos, que describiremos más adelante.
• La calidad extrínseca es la calidad del producto tal como lo percibe el usuario final. Qué tan bien el producto se adapta a sus necesidades y cumple con las expectativas. Otro término para esta cualidad extrínseca es valor.

Por lo tanto, es importante comprender que la calidad representada en el triángulo ágil es una calidad intrínseca o interna desde el punto de vista del desarrollo, mientras que el valor en el triángulo es realmente una forma de calidad extrínseca. Comprender esta relación es importante para desarrollar buenas medidas ágiles.

17 métricas ágiles clave para rastrear

La siguiente lista de diecisiete métricas combina las métricas ágiles más utilizadas y tradicionales con medidas más nuevas basadas en investigaciones recientes. La conclusión clave aquí es que cualquier solución de métricas ágiles debe ser integral.

Confiar solo en uno o dos no proporcionará una imagen completa de lo que está sucediendo. El mayor error que cometen muchos gerentes es centrarse demasiado en dos o tres, o solo en una métrica para todo su proyecto. Algunas organizaciones solo usan gráficos de velocidad o de quemado.

Lo creas o no, sucede. Una buena solución de métricas debe cubrir los tres puntos del triángulo ágil. Estos 17 te darán las herramientas para hacer precisamente eso y mucho más.

tiempo bloqueado

El tiempo bloqueado se define como la cantidad de tiempo que una historia de usuario en particular, o a veces una tarea, está bloqueada. Resolver los bloqueos es fundamental para facilitar el flujo de trabajo en un entorno ágil, y esta métrica puede ayudar a medir la cantidad de tiempo que tardan en resolverse. Los bloqueadores deben resolverse de manera conveniente.

Los aumentos en el tiempo bloqueado podrían significar que una historia de usuario no se descompuso correctamente o que existe una dependencia de un recurso externo que no fue planificado. El tiempo bloqueado se puede reducir con una descomposición más cuidadosa de la historia del usuario, la priorización y la planificación de sprints.

Impulso empresarial

Muchas de las métricas discutidas aquí han existido durante bastante tiempo. La mayoría se centran en el nivel de proyecto, equipo o WIP (trabajo en curso). Sin embargo, a medida que la tecnología está más integrada en nuestra vida diaria y los mercados para esos productos se aceleran, las organizaciones buscan métricas más sofisticadas que puedan identificar las tendencias del mercado, medir la mejora del proceso, predecir la competencia y, en esencia, medir la agilidad. El impulso empresarial es uno de ellos. El impulso en este contexto se puede expresar como el total de puntos de la historia de un lanzamiento multiplicado por su línea de tiempo.

A medida que una organización se vuelve más ágil, gana impulso con cada lanzamiento. Los tiempos de ciclo tienden a acortarse y crecen las expectativas en torno a la entrega. El impulso del negocio se puede utilizar para la sincronización del mercado o como marcador de la salud de una línea de productos o programa en particular. Si el impulso comienza a disminuir, esto es un indicador para la gerencia de que un mercado en particular está comenzando a desarrollarse y se debe desarrollar una nueva línea de productos. Las organizaciones ágiles deben buscar continuamente nuevos mercados para seguir siendo competitivas.

Cobertura de código

La cobertura de código es una medida de la cantidad de código que se ejecuta realmente durante la prueba. Esto normalmente se instrumenta y calcula como parte de una estrategia de prueba automatizada. La métrica debe proporcionar el porcentaje general de código ejecutado durante cada fase de prueba (unidad, sistema, etc.), así como el total de todas las fases.

La cobertura del código no debe utilizarse de forma indebida como marcador de lo bien que se ha probado un producto. Más bien, el objetivo de esta métrica es facilitar la automatización de pruebas y monitorear la entrega continua. Las medidas de garantía de calidad deben incluir una variedad de métricas, entre las que se encuentran las ocurrencias de defectos que se analizan más adelante.

Tabla de control

A veces denominado gráfico de comportamiento del proceso o gráfico de Shewhart, un gráfico de control supervisa el rendimiento de un proceso para determinar si está bajo control o fuera de control, según los límites de control superior, inferior y medio que se hayan establecido.

Estos límites se calculan estimando la desviación estándar de los datos de la muestra, multiplicando esa desviación por tres y luego sumando eso al promedio para crear el límite superior y restándolo del promedio para crear el límite inferior. El eje Y del gráfico es el número de ocurrencias o problemas en una muestra en particular, mientras que el eje X enumera cada muestra. Los gráficos de control se originaron en la fabricación como una forma de control de calidad y existen desde hace casi 100 años.

Popular entre los discípulos de Six Sigma, los gráficos de control pueden medir el fracaso o el éxito del control de calidad u otros procesos de fabricación. Si bien no se popularizaron en el mundo ágil, los gráficos de control podrían usarse para medir los defectos encontrados por iteración o lanzamiento para identificar problemas de pruebas de control de calidad, o para medir los tiempos de ciclo en una serie de lanzamientos para garantizar que se encuentren dentro de los niveles aceptables.

Diagrama de flujo acumulativo

Un diagrama de flujo acumulativo ilustra cuánto trabajo, segmentado por tipo, se asigna a un equipo a lo largo del tiempo. Su propósito es monitorear qué tan bien fluye el trabajo en todo el sistema. En este diagrama, el trabajo se divide en diferentes tipos, por ejemplo: por hacer, en progreso y terminado. También podría dividirse en requisitos, desarrollo, pruebas, etc. Independientemente de cómo esté segmentado, el diagrama de flujo acumulativo muestra una línea para cada tipo de trabajo, con el número de elementos de trabajo en el eje Y y el eje X en función del tiempo.

El buen flujo se ilustra con todas estas líneas que corren en paralelo. Si una de las líneas experimenta un repunte brusco o se cruza con otra, esto podría indicar un cuello de botella. Lograr un buen flujo es el concepto central detrás de kanban. El diagrama de flujo acumulativo ayuda a identificar cuellos de botella para facilitar el flujo continuo y garantizar que WIP no se salga de control en ningún punto del sistema.

Tiempo del ciclo

El tiempo de ciclo se puede definir como el tiempo que lleva producir una versión de software, desde el concepto hasta la finalización. Junto con el tiempo de entrega y la velocidad, el tiempo de ciclo es un muy buen indicador de alto nivel de la salud ágil y el éxito de la transformación ágil. A medida que una organización avanza en su viaje ágil, los tiempos de ciclo deberían disminuir gradualmente, generalmente a seis meses o mucho menos. Los aumentos en el tiempo del ciclo, especialmente cuando se observan constantemente durante una o dos liberaciones, deben ser motivo de preocupación y revisión.

Burndown épico y de lanzamiento

Los gráficos de trabajo pendiente épicos y de lanzamiento son similares al siempre popular trabajo pendiente de sprint que se analiza a continuación. Un gráfico de trabajo pendiente ilustra cuánto trabajo queda para un período de tiempo determinado o, en este ejemplo, para una epopeya determinada. En el desarrollo ágil, una épica es una historia de usuario más grande compuesta de historias de usuario más pequeñas o fragmentos de trabajo.

A medida que se completa el trabajo, la cantidad de historias de usuarios en la épica se reduce gradualmente hasta llegar a cero. Esto puede ser útil en los casos en que se deben alcanzar hitos para cumplir con los requisitos contractuales y facturar al cliente. Del mismo modo, un avance de versión puede realizar un seguimiento del progreso del trabajo comprometido para una versión específica. Esto se puede usar para ayudar a garantizar la entrega a tiempo o identificar la necesidad de cambiar una fecha límite antes de tiempo.

Implementaciones fallidas

Una implementación fallida es aquella que resulta en cualquiera de los siguientes:

• Servicio que afecta la interrupción
• No cumple con las expectativas del cliente, lo que a menudo resulta en el rechazo del lanzamiento.
• Afecta gravemente la usabilidad, el funcionamiento o la experiencia del usuario del producto.
• Da como resultado una reversión a la versión anterior.

Obviamente, la tasa de implementación fallida, que se muestra como un porcentaje de las implementaciones totales, debe mantenerse al mínimo. Cualquier pico en esta métrica debería ser motivo de preocupación. Las tasas de cambio y las ocurrencias de defectos deben revisarse para aislar las causas raíz.

Tiempo de espera

El tiempo de entrega mide el tiempo que lleva completar una tarea, desde el momento en que se crea hasta el punto en que se termina. En resumen, identifica cuánto tiempo lleva hacer las cosas. Popular entre los practicantes de kanban, esta métrica puede ayudar a identificar eficiencias para mover tareas más rápido a través del sistema. También se puede usar como una métrica de alto nivel para determinar qué tan bien está funcionando la entrega continua. El tiempo de entrega, junto con el tiempo y la velocidad del ciclo, se pueden usar juntos para proporcionar una visión holística del rendimiento de la entrega.

Puntuación neta del promotor (NPS)

La puntuación neta del promotor está destinada a ayudar a calificar la satisfacción del cliente. Por lo general, se calcula en función de los datos obtenidos a través de una encuesta. El objetivo es averiguar cuántos clientes recomendarían su producto. El porcentaje de encuestados que votan "no" se resta de los votantes "sí" para crear el puntaje.

Además de medir la satisfacción del cliente, la puntuación neta del promotor puede ayudar a identificar a los clientes más dispuestos a colaborar en productos o tecnologías innovadores para lanzamientos futuros. Dichos clientes pueden convertirse en una ventaja competitiva, ya que sus comentarios y apoyo pueden ayudar a las empresas a comercializar nuevos productos antes que la competencia.

Inteligencia de calidad

Al comienzo del artículo discutimos el triángulo ágil y el papel que juega la calidad en él. La inteligencia de calidad puede tomar muchas formas, pero generalmente se compone de una variedad de métricas de seguimiento de defectos. Los defectos se pueden monitorear en función de dónde y cuándo ocurren, su frecuencia y gravedad.

Uno de los más populares es la tasa de escape de defectos, que es la relación entre los defectos encontrados por el cliente y el número total de defectos descubiertos en una versión. Aunque un gran número de defectos debería ser preocupante sin importar cómo se encuentren, siempre es mejor detectarlos antes de que lo haga el cliente.

Quemado de Sprint

Los gráficos de trabajo pendiente de sprint proporcionan una medida diaria del trabajo que se completa y el trabajo que queda por hacer en un sprint determinado. Compara la cantidad de trabajo completado con las estimaciones originales. Debido a la naturaleza empírica del desarrollo ágil, el valor del burndown chart es bastante limitado.

A pesar de su popularidad, muchos entrenadores ágiles están dejando de usarlo tanto como antes. Puede servir como una buena guía o punto de estado para saber dónde se encuentran los equipos de desarrollo frente a sus compromisos, pero debe usarse junto con otras métricas para obtener una imagen completa de lo que está sucediendo.

Rendimiento

La cantidad de producto (número de elementos de trabajo) entregados al cliente por una unidad de tiempo particular se conoce como rendimiento. Esto podría medirse mensualmente, trimestralmente, por versión, iteración, etc. El valor de esta métrica es que se puede usar para determinar cuánto software se puede entregar durante un período de tiempo específico. También se puede usar para rastrear la consistencia de la entrega desde una perspectiva de equipo y organización.

El análisis empírico de los datos históricos se puede utilizar para pronosticar el rendimiento de la entrega. Cuantos más datos históricos estén disponibles, más precisas serán las proyecciones. Lo que es más importante, esta métrica también se puede usar para pronosticar los ingresos, dado que el valor de la funcionalidad de la función entregada se comprende bien en términos financieros. Para que esta métrica funcione, la definición de "hecho" debe estar bien definida. Solo el software entregado al cliente cumple con este requisito.

Valor entregado

Al comienzo del artículo discutimos cómo el valor consiste en la calidad extrínseca, o la percepción del producto por parte del usuario final. ¿Cómo impacta el producto en el negocio del cliente? Las buenas métricas ágiles se basan en los resultados y, en el mundo de los negocios, eso generalmente se traduce en dólares y centavos. Así como asignamos puntos de historia a cada historia de usuario como una forma de estimar el trabajo que requiere, también podemos agregar puntos de valor como una medida relativa para indicar lo que obtiene el usuario final cuando termina el trabajo.

Una forma de hacerlo es con un gráfico de quemado que ilustre la cantidad de puntos de valor acumulados a medida que se completa cada historia. Se pueden asignar puntos de valor a cada historia o función en función de la percepción del cliente a medida que se crean los criterios de aceptación. Los ingresos esperados (o el dinero ahorrado) para el cliente en el proyecto se pueden dividir por el número total de puntos de valor en el lanzamiento.

Por ejemplo, si hay 200 puntos de valor en un proyecto y se espera que el cliente obtenga 1 millón de dólares en ingresos, entonces cada punto de valor vale $5000. La suma total de cada piso y su valor acumulado se pueden ilustrar en el gráfico de quemado. Aunque es posible que el impacto real del producto no sea evidente hasta que se lance, este método puede proporcionar inteligencia financiera convincente tanto para la gerencia como para los clientes.

Velocidad

La velocidad es probablemente la primera métrica de la que la mayoría de nosotros escuchamos después de conocer el desarrollo ágil. Aunque podría decirse que es la métrica ágil más popular, también es la más mal utilizada. Los equipos de Sprint son conocidos por la velocidad de los juegos porque se depende en gran medida de ellos para informar sobre su rendimiento. La velocidad se define como la cantidad de software producido en cada iteración o sprint. Esta cantidad generalmente se expresa como puntos de la historia y el software producido debe ser una porción de código lista para la producción funcional.

Los equipos suelen acelerar el juego al manipular el tamaño y la estimación de las historias de los usuarios, o al descomponer el trabajo horizontalmente, en lugar de verticalmente, mediante la creación de historias para cambios en la base de datos, trabajo de front-end, middleware y más. para eliminar las dependencias de otros y obtener crédito por completar el trabajo. El problema con este enfoque es que ese tipo de historias de usuarios son realmente tareas, y aunque los equipos obtienen crédito, no se ha entregado valor comercial para el cliente.

La velocidad del juego se puede evitar mediante el uso de una serie de otras métricas como control y equilibrio entre sí. Con demasiada frecuencia, las organizaciones confían únicamente en la velocidad o en un conjunto muy pequeño de métricas en lugar de un conjunto más amplio de medidas para formar una solución de gestión de proyectos, programas y PPM.

Vorticidad (ágil)

Una pregunta con la que luchan muchos agilistas y gerentes de proyectos es "¿qué tan ágiles somos?" De hecho, la búsqueda de la respuesta para medir la agilidad en sí misma ha sido el santo grial de los agilistas de todo el mundo. La vorticidad ágil es una nueva medida que hace precisamente eso. Basado en más de 10 años de investigación de estudios de casos, la vorticidad ágil se desarrolló a través de un método cualitativo sofisticado llamado teoría fundamentada.

Usando un conjunto integral de medidas, la agilidad tanto del mercado como del proceso organizacional se puede comparar entre sí para determinar su vorticidad o el punto en el que convergen. La vorticidad cero significa que la agilidad de la organización está a la altura del mercado. Alta vorticidad significa que el mercado se mueve mucho más rápido que su organización o equipos y, por lo tanto, hay mucho trabajo por hacer. La siguiente infografía demuestra esta relación mediante un experimento mental en espiral para ilustrar los mercados hiperacelerados de la actualidad.

Edad del elemento de trabajo

Un elemento de trabajo podría definirse como un paquete de trabajo, una función utilizable o, como sería en la mayoría de los contextos ágiles, una historia de usuario. El reloj comienza a marcar la edad de un elemento de trabajo tan pronto como se concibe por primera vez. El seguimiento de la antigüedad de los elementos de trabajo, ya sea que estén en progreso o en espera, puede ayudar a identificar problemas con los requisitos.

Si un elemento de trabajo parece estar envejeciendo más que su pariente porque se desplaza de un sprint al siguiente, podría haber un problema con la descomposición. ¿Tal vez necesita ser redefinido o mejor entendido? Es posible que sea necesario eliminar o redefinir los elementos de trabajo que se encuentran en la cartera de pedidos durante períodos prolongados.

La preparación continua del backlog es fundamental para la planificación y priorización de sprints. Un número creciente de requisitos obsoletos en la cartera de pedidos podría significar problemas con la forma en que se desarrollan y descomponen los requisitos. La gestión deficiente de los requisitos es una de las causas principales del fracaso en las transformaciones ágiles.

Los requisitos mal escritos pueden hacer que la priorización y la estimación sean extremadamente difíciles, lo que resulta en una deuda técnica fuera de control, una baja utilización de funciones y pérdidas financieras. Desarrollar requisitos bien entendidos, priorizados y de alto valor es en gran medida una forma de arte y mal entendido incluso por los mejores agilistas. De hecho, podría decirse que es uno de los mayores obstáculos para el éxito de la transformación ágil.

Conclusión

En este artículo, hemos establecido la base para las métricas ágiles, la necesidad de una solución integral y 17 recomendaciones para crear una. Ya sea que use todas las medidas discutidas o solo un subconjunto, es importante que cualquier solución considere la audiencia de los datos. Algunas métricas, como la velocidad, se mantienen mejor dentro de los equipos de scrum. Otras métricas, como la vorticidad ágil y el impulso comercial, están diseñadas para la gestión ejecutiva o de productos, respectivamente.

Siempre asegúrese de comprender completamente y comunicar con precisión lo que dicen las métricas, y siga a dónde conducen los datos. Una forma de impulsar y respaldar buenas métricas es con un marco ágil robusto.