Las métricas ágiles son medidas utilizadas para realizar un seguimiento del progreso y el éxito de un equipo de proyecto ágil.
Las métricas, cuando se definen de la manera correcta, brindan información sobre el rendimiento, la calidad, la eficiencia de las pruebas o la efectividad general del equipo y cómo evoluciona con el tiempo.
El objetivo final de las métricas ágiles es ayudar a los equipos a identificar áreas de mejora y tomar decisiones basadas en datos que conducirán a mejores productos a medida que el equipo avanza.
La mayoría de las veces, las empresas definen métricas que son métricas de vanidad o números sin procesar, que crecen de izquierda a derecha. Pueden verse bien en algunos tableros, pero por lo general son inútiles para el propio equipo.
Su propósito no es ayudar al equipo de ninguna manera, sino completar algunos informes para el liderazgo y luego concluir con algunas decisiones estratégicas. Desafortunadamente, es el equipo quien no entiende por qué existe esta decisión en particular.
En una valla para cumplir con métricas tan incorrectas, los equipos falsifican sus propios procesos para que las métricas se vean bien. Pero el rendimiento del equipo no mejora en absoluto.
Tabla de contenido
Métricas básicas
Hay muchas formas de segregar las métricas. Quizás el más básico es de arriba hacia abajo y de abajo hacia arriba.
➡️ De arriba hacia abajo significa: Nosotros, los líderes, crearemos para usted las métricas que queremos que todos ustedes cumplan, y su objetivo final es encajar en las áreas verdes de esas. No nos importa si usted, un equipo como ellos o no; esto es lo que queremos rastrear.
➡️ De abajo hacia arriba significa: nosotros, el equipo, debemos mejorar en esas áreas y, para eso, debemos centrarnos en estas cosas. Por lo tanto, definimos métricas que nos permitirán rastrear el progreso del equipo hacia nuestros objetivos, y podemos demostrarle a usted, liderazgo, cómo exactamente mejoró nuestro trabajo con el tiempo.
Definición de buena métrica
Entonces, ¿qué debe contener cualquier buena métrica o cómo describirla?
La propiedad más importante es el cambio de comportamiento. Esto significa que cada vez que observa el resultado de la métrica, está claro qué debe cambiar dentro del equipo para obtener mejoras.
Entonces debe ser sencillo. Si no puede explicarlo con unas pocas oraciones simples para que todos los oyentes relevantes puedan entenderlo, entonces algo no es realmente bueno.
Una buena métrica es comparable a lo largo del tiempo. Tome una instantánea de los resultados en un momento, luego vuelva a hacerlo más tarde. Colóquelos uno al lado del otro. Si no puede comparar los dos resultados entre sí, debe pensar en esta métrica dos veces.
Por último, mejor que los números puros, siempre que sea posible, que sea una relación o un porcentaje. “10 nuevos defectos abiertos durante el sprint” no dirá mucho. Depende si normalmente tienes uno o 100.
Aquí hay algunos ejemplos de métricas que creo cumplen con todos esos criterios de definición. Tienen en mente equipos específicamente ágiles. Hay tres categorías principales: rendimiento, calidad y moral.
Categorías de Métricas
Métricas de rendimiento
El objetivo es comprender qué tan bueno es el equipo para ponerse al día con las historias comprometidas dentro de un sprint. Para evaluar si el exceso de compromiso no es lo habitual o si las historias remanentes son un estándar de sprint a sprint.
Desde la perspectiva del rendimiento ágil, el equipo se esforzará por entregar el contenido del sprint planificado con el que se comprometió al comienzo del sprint.
No significa que no seremos flexibles en el intercambio de historias durante el sprint. Pero siempre debe ser una negociación que lleve a un intercambio, no a una adición. La capacidad del equipo no crecerá solo porque alguien agregó nuevas historias dentro del sprint.
Traemos esta métrica para estar atentos a tales casos y guiar a todos en el equipo para proteger la capacidad que tienen para el sprint.
Esto aumenta la fiabilidad y la previsibilidad del equipo.
#1. Capacidad de Sprint vs. Story Points entregados
Vea el historial de capacidad de sprint frente al contenido de puntos de historia entregados (SP) durante los sprints.
- Las pequeñas desviaciones de sprint a sprint están bien. Grandes saltos en cualquier dirección indican que algo está mal.
- Capacidad total de Sprint: el día disponible de un miembro del equipo agrega uno a la capacidad total. Por ejemplo, si el equipo tiene 10 personas y todas ellas estarán disponibles en el sprint completo, entonces la capacidad total para el sprint es de 100.
Verifique la capacidad del sprint frente al SP completado de sprint a sprint. Si el equipo se está comprometiendo (durante la planificación) con una cantidad significativamente mayor de SP de lo que el equipo normalmente puede completar, eleve este riesgo al equipo.
El objetivo será tener un SP planificado total igual o menor que el SP total completado por sprint.
Todavía puede tener más SP completos de los planificados si el equipo completó (hacia el final del sprint) todas las historias planificadas y el equipo todavía tiene la capacidad de tomar la historia adicional.
- Si el equipo entrega repetidamente menos SP de lo planeado, el equipo debe modificar su planificación y tomar menos SP en el próximo sprint.
Herramientas como monday.com, Atlassian Jira o Asana proporcionan una forma sencilla de guardar y extraer puntos de historia por cada historia en los sprints. Incluso pueden generar eso automáticamente después de cada planificación de sprint.
#2. Cuadro de incendio
Esta es una de las métricas que probablemente la mayoría de los equipos de scrum tienen escondidas en algún lugar del tablero. Estoy de acuerdo en que esto podría incluso parecer algo inútil. El equipo rara vez lo toma en consideración. Más bien, al gerente le gusta señalar cómo se ven las historias desde un nivel alto y cómo no están progresando bien (ya que todas están abiertas durante todo el sprint).
Lo que me gustaría resaltar es que, a pesar de eso, ustedes como equipo deben ir y revisar el gráfico de trabajo pendiente por su propio bien. Si todas las historias están abiertas durante todo el sprint y solo se cierran el último día del sprint, esto crea incertidumbre dentro del equipo y hacia la finalización de los objetivos del sprint.
- Revise su tablero de sprint para ver las historias completadas.
- Consulte con el equipo para determinar por qué las historias pequeñas aún están abiertas, incluso si comenzaron al comienzo del sprint.
- Trabaje con el equipo para desarrollar esa mentalidad, no para mantener las historias abiertas más tiempo del necesario.
- El diagrama de quemado ideal suele ser un estado teórico. Sin embargo, cuanto más nos acercamos a él, más eficaz es el manejo de la historia.
Las herramientas de gestión ágiles como Asana pueden generar automáticamente un gráfico de trabajo pendiente para cada sprint.
Fuente: asana.com
#3. Finalización de objetivos de Sprint
Esto rastrea el porcentaje de Sprint Goals que completó durante cada sprint.
Los objetivos del Sprint se documentan por separado, por ejemplo, en la página Confluence/Jira, para cada Sprint. El estado se asignará ya sea que se hayan cumplido o no dentro del sprint.
Incluso si el equipo no completó todas las historias dentro de un sprint, aún podría lograr el objetivo del Sprint (por ejemplo, solo faltan las historias secundarias).
Apuntaremos a completar el 100% de los Objetivos de Sprint en cada Sprint. Si ese no es el caso, averigüe lo que el equipo está evitando.
- Si son demasiados temas paralelos en cada sprint, reduzca la cantidad de ellos.
- Si se agregan demasiadas historias ad hoc durante el sprint, reduzca esto para que no afecte los objetivos originales del sprint.
- Si los objetivos del sprint son demasiado grandes o demasiado desafiantes, hazlo más simple. De todos modos, no tiene sentido tener grandes objetivos de sprint y no cumplirlos al final del sprint.
Métricas de calidad del código
Esto hará un seguimiento de la calidad del código a lo largo del tiempo. Ayuda a mantener procesos de desarrollo saludables y disminuye el tiempo dedicado a resolver problemas. O el tiempo de inactividad del desarrollador causado por la espera de la ejecución del código durante las actividades de desarrollo y prueba.
Fuente: azuredevopslabs.com
#1. Pruebas automatizadas
Cree pruebas unitarias automatizadas por parte de los desarrolladores para cada cambio que realicen.
- Mida la cobertura del código mediante pruebas automatizadas: use Azure Pipelines o SonarCloud para ejecutar las pruebas. Apunta a una cobertura del 85%. Por encima del 90% no es realmente eficiente.
- Asegúrese de que la creación de pruebas unitarias automatizadas sea parte de la definición de hecho para las nuevas historias.
- Póngase al día con la cobertura de prueba de código antiguo como parte de las historias de deuda técnica en la cartera de pedidos.
#2. Complejidad del código
Evalúe las complicaciones innecesarias que el código está obteniendo con el tiempo y arréglelas activamente mediante historias de deuda técnica. O evitar que sucedan si es posible.
Defina estándares y pautas de código para educar a los desarrolladores para que los sigan. Asegúrese de que cumplan con las reglas de codificación para minimizar el aumento irrazonable de la complejidad del código. Actualización periódica de las directrices en función de la experiencia del equipo.
Identificar olores de código: indicadores de posibles problemas en el código, como código duplicado, métodos largos y variables no utilizadas.
Las revisiones por pares garantizarán que los estándares del código se apliquen al código recién creado.
Utilice herramientas como los paneles e informes de Azure Ado o SonarCloud para descubrir problemas de código.
#3. Pasos manuales en la implementación
Realice un seguimiento de cuántos pasos manuales debe realizar el equipo para publicar el código en entornos de prueba o producción.
- Nuestro objetivo será lograr el 0 aquí con el tiempo.
- Cree historias de deuda técnica si es necesario para llevar la canalización de implementación/lanzamiento a la hoja de ruta de automatización. Reduzca gradualmente los pasos manuales restantes en los procesos de sprint a sprint.
Métricas de moral
Esta es una métrica para rastrear cómo se siente el equipo sobre su trabajo y los procesos con los que se enfrentan a diario.
#1. Cumplimiento retrospectivo de Sprint
Puede realizar un seguimiento de cuántos elementos de acción se completaron realmente en el siguiente sprint.
- Scrum Master recopilará los resultados de la reunión retrospectiva en las páginas del equipo para realizar un seguimiento de los elementos de acción acordados.
- El equipo luego realizaría un seguimiento del progreso.
- Luego, la gestión de proyectos puede revisar si los elementos de acción están progresando o qué impide que el equipo los complete. Luego modifique el entorno para permitir que el equipo progrese en los elementos de acción acordados.
Al menos el 33% o 1 (dependiendo de lo que sea más alto) de los elementos de acción del sprint anterior se adoptarán en los próximos sprints.
Si es menor que eso, se necesitan cambios para permitir que el equipo implemente las mejoras que acordaron.
Las herramientas de gestión de proyectos contienen plantillas listas para usar para actividades retrospectivas de sprint. Aquí hay un ejemplo de monday.com:
Fuente: lunes.com
#2. Colaboración en equipo
Programación de pares de pistas.
- Formar una pareja natural por historia para trabajar juntos, compartiendo observación, conocimiento y éxito. Cree subtareas bajo historias propiedad de diferentes miembros del equipo.
Realice un seguimiento de las revisiones del código de las iniciativas de sus compañeros.
- Se les pide a los compañeros que tomen medidas de manera proactiva para revisar el resultado de la historia de otra persona.
La métrica se puede extraer del tablero monday.com/Asana/Jira de las subtareas.
Al menos el 50% de las historias en el sprint deben ser compartidas por miembros del equipo. Si es menor, investigue las razones y tome medidas donde tenga sentido.
Para revisiones voluntarias por pares, realice un seguimiento de las historias con subtareas dedicadas. Al principio, el 20 % de las historias de código revisadas de esta manera es un buen comienzo. Gradualmente a lo largo de los sprints, animarás y motivarás al equipo a trabajar de manera más colaborativa y aumentarlo hacia el 50 % de las historias de código por sprint como meta.
#3. Deuda técnica frente a nuevas historias de funcionalidad
Fuente: atlassian.com
Darle al equipo la oportunidad de resolver sus propias historias de deuda aumentará la satisfacción del equipo con su trabajo.
- Por el contrario, la acumulación de problemas de deuda tecnológica sin un plan para resolverlos progresivamente desmotivará al equipo con el tiempo. Y la solución se volverá más inestable, compleja y difícil de resolver sin una revisión sustancial.
El equipo sabe mejor lo que no funciona bien con la solución, incluso si las partes interesadas o los usuarios finales no lo ven. Tales historias tienen el mayor impacto en el propio equipo de desarrollo. Para las partes interesadas, pueden ser invisibles. Por eso es importante darle al equipo la oportunidad de trabajar en historias que les ayuden a despejar las actividades de desarrollo.
El objetivo es rastrear cuántas historias de deuda técnica planteada se resuelven con el tiempo y si la acumulación de dichas historias solo crece o no.
El equipo puede etiquetar las historias como TechDebt en el backlog y darles prioridad del equipo, para que puedan estar en la cima y ser seleccionadas en sprints.
Según el estado en el que se encuentre el proyecto y cuántas deudas tecnológicas se identifiquen en el backlog, es posible que desee asegurarse de que el backlog de TechDebt no crezca más del 10 % de un sprint a otro.
Priorice las historias de deuda tecnológica e inclúyalas en los sprints para mantener bajo control el crecimiento de la acumulación de deuda tecnológica, de modo que el equipo pueda trabajar en las historias de deuda tecnológica entre un 10 y un 20 % del tiempo en cada sprint.
Ultimas palabras
Cada proyecto eventualmente necesitará algunas métricas, ya sea porque el liderazgo quiere tenerlas o porque el equipo decide medir su propio éxito.
Lo mejor que puede hacer es comenzar a construir su biblioteca de métricas listas para ser seleccionadas y utilizadas; cuanto antes mejor. Y mientras hace eso, asegúrese de buscar siempre métricas que cambien el comportamiento por encima de todo.
A continuación, echa un vistazo a los procesos no saludables que pueden arruinar tu sprint.