La métrica más importante en un proyecto ágil como Scrum es el valor que se está dando al cliente. Mediante esta métrica, el cliente puede conocer la velocidad con que retorna su inversión y saber cuándo ya no es necesario seguir con el proyecto, por que los beneficios pendientes de obtener ya no compensan sus costes.
Sin embargo, cuando se mide a una persona o a un equipo de una determinada manera, sus acciones pueden desviarse en exceso hacia ese objetivo y descuidar otros aspectos también importantes como, por ejemplo, la calidad, los costes, los riesgos, la sostenibilidad de la velocidad con que obtienen objetivos, etc. Por ello, puede ser necesario utilizar un conjunto de métricas de diferentes aspectos relacionados, creando de esta manera un cuadro de mandos integral ágil (agile balanced scorecard).
- El porcentaje de completitud de un objetivo o requisito: en un proyecto ágil, para poder determinar cuando se completa un requisito o entrega se utiliza concepto de esfuerzo pendiente, así como qué objetivos están completados o cuáles no (al cliente no le interesan los que están en curso ya que no puede hacer uso de ellos)
- Los diagramas de Gantt: no aportan más información que la que aportan las herramientas propias de Scrum.
- Velocidad con que se completan objetivos/requisitos en cada iteración. Idealmente debería aumentar con respecto al tiempo (productividad). También permite ir extrapolando la fecha de finalización del proyecto en función de cuando se vaya a completar todo su alcance.
- Tiempo de entrega de un requisito tras su petición o Lead Time (responsividad a necesidades del cliente, Time to Market, tiempo de servicio), en función de la criticidad de la petición (urgente, etc.) y cumplimiento de los Acuerdos de Nivel de Servicio (ANS / SLA).
- Urgencias y prioridad/valor de los requisitos completados, para comprobar si existe desalineamiento con los objetivos del proyecto y/o la estrategia de la organización.
- Velocidad con que se aporta valor al negocio (desde el punto de vista del cliente).
- Valor acumulado.
- Requisitos completados en la iteración.
- Próximos requisitos a desarrollar.
- Cambios incorporados y requisitos añadidos sobre el alcance inicial del proyecto.
- Número de requisitos completados respecto al total de requisitos (métrica que también permite observar cambios de alcance).
- Días de trabajo ideales pendientes (métrica que permite proyectar la fecha de finalización del proyecto).
- Desviación de resultados de proyecto respecto a planificación inicial.
- Retorno de Inversión (ROI) pendiente, el valor pendiente respecto al coste pendiente, para saber cuándo finalizar el proyecto (ver la cláusula de finalización anticipada del contrato en el artículo Un contrato ágil para Scrum).
- Presupuesto disponible y/o presupuesto gastado.
- Desviación financiera respecto a la planificación inicial.
- Satisfacción del cliente / usuario, respecto a los resultados del proyecto y a la colaboración con el equipo.
- Ambiente en el equipo
- Incidencias (defectos encontrados por el cliente o usuarios del producto), por estado y por criticidad.
- Errores (defectos detectados internamente, bugs), por estado y por criticidad.
- Cobertura de las pruebas.
- Trazabilidad.
- Días de deuda técnica.
- % de código en SCM (e.g. GIT), motor CI (e.g. Jenkins), herramienta de control de calidad de código (Sonar).
- Separando las partes «nuevas / refactorizadas» del monolito.
- Cumplimiento de estándares de codificación, normativas, regulaciones, etc.
- Comentarios en el código.
- Complejidad ciclomática del producto.
- Tamaño de las operaciones.
- Calidad de la documentación (existencia y cobertura de la documentación funcional, técnica, de pruebas, de implantación, operativa, etc.).
- Riesgos (severidad y mitigaciones) e impedimentos: considerando las dependencias o sinergias con otros equipos o proyectos, la implicación del cliente, los problemas tecnológicos, el resultado de las retrospectivas, etc.
- Lecciones aprendidas.
- Actividades de mejora a planificar (comunicaciones, formaciones, soporte, herramientas, etc.).
- Uso de prácticas específicas: número de integraciones, tiempo de refactorización, de TDD, revisiones expertas, etc.
- Situaciones anómalas: sobreesfuerzo, requisitos no completados, terminaciones anormales de iteración, interrupciones, sospechas de mala aplicación del proceso (por ejemplo, si el cliente se muestra sorprendido en la demostración de la iteración), etc.
- % de personas que no intervienen en las reuniones diarias de sincronización.
- Métricas de iteración (Scrum sprint metrics)
- Productividad y ejemplo de organización ágil
- Métricas ágiles y valor – VI encuentro ágil en Barcelona
- La Ingeniería del Software tiene aún muy poco camino recorrido – Juan Palacio. Sobre Tom DeMarco y su rectificación en el uso de métricas Software Engineering: An idea whose time has come and gone: «las métricas tienen que tomarse como un grano de sal, en lugar de confiar en ellas sin reservas» y «hay que trabajar en proyectos que aporten mucho valor y donde el control no sea tan importante».
- Appropriate Agile Measurement: Using Metrics and Diagnostics to Deliver Business Value – Deborah Hartmann y Robin Dymond
- Agile Metrics – Dave Nicolette.
- The Enterprise and Scrum – Ken Schwaber. Libro que explica cómo escalar y implantar Scrum a nivel organizativo.