Métricas ágiles y cuadro de mandos integral para Scrum

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).

graficos-progreso-scrum

 
Selección y uso de las métricas
Respecto al valor aportado al proyecto, es recomendable que esté basado en un único indicador económico clave con el que el cliente pueda medir todos los objetivos del proyecto, de forma que permita guiar la toma de decisiones y la forma de invertir en el proyecto.
Para el resto del cuadro de mandos se debe escoger el mínimo número de métricas que permita tomar decisiones sobre los resultados del proyecto y las necesidades del cliente (tras un análisis causal de los problemas que están mostrando, siempre recordando que el uso de una métrica puede condicionar la actuación de las personas). Se debe minimizar tanto el coste e impacto que se añade al trabajo ordinario del equipo (hay que ir registrando lo que sucede, cosa que puede incluso desvirtuar la métrica) como su coste de recolección, proceso y presentación. Por todo esto, cuando un problema específico esté resuelto, hay que plantear si tiene sentido seguir recogiendo las métricas asociadas.
Es conveniente mostrar en el cuadro de mandos los objetivos de la iteración, entrega, proyecto, programa u organización, según sea el ámbito del cuadro de mandos (mostrar la velocidad con que se consiguen los objetivos del proyecto o guiar e informar sobre la estrategia de la organización y su cumplimiento).
En los equipos ágiles es común que las métricas surjan ante una necesidad del equipo, como una forma de mejorarse. Por ejemplo la velocidad del equipo puede ser una herramienta para que el equipo planifique y tome compromisos, e incluso para cuantificar una mejora.
Será fundamental presentar las tendencias de las métricas a lo largo del tiempo (los valores en un momento dado pueden deberse a situaciones puntuales), con diferentes niveles de agregación en función de las necesidades: diario, iteración, etc.
 
Métricas ágiles del cuadro de mandos
La mayoría de las métricas más importantes derivan de las herramientas propias de Scrum (la lista de requisitos priorizada, la lista de tareas de la iteración y los gráficos de trabajo pendiente), por lo que el momento natural para actualizar este cuadro de mandos es tras la retrospectiva de la iteración.
Notar que en una gestión ágil de proyectos carece de sentido utilizar algunas de las métricas más utilizadas en proyectos tradicionales o en cascada, como por ejemplo:
  • 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.
Las métricas de uso más común se muestran en negrita. Las que no aparecen en negrita se muestran como ejemplos de métricas que se pueden utilizar de manera más temporal para analizar problemas concretos.
Métricas de productividad y efectividad de la entrega
  • 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.
Métricas de resultados del proyecto
  • 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.
Métricas de situación financiera
  • 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.
Métricas de calidad
Expectativas:
  • Satisfacción del cliente / usuario, respecto a los resultados del proyecto y a la colaboración con el equipo.
  • Ambiente en el equipo
Calidad funcional:
  • 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.
Mantenibilidad:
  • 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.).
Métricas de riesgos, impedimentos, proceso y mejora continua
  • 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.
 
Conclusiones sobre el estado del proyecto
Este apartado debe contener un resumen con las métricas más importantes y las relaciones entre ellas, así como las lecciones aprendidas y próximas acciones de mejora (tras un análisis causal de problemas como, por ejemplo, el que se realiza en una retrospectiva), de manera que el cliente pueda tomar decisiones informadas y dirigir los resultados del proyecto.
Hay que recordar que muchos de los problemas detectados y disfuncionalidades de la organización ya estaban ahí antes de utilizar una gestión ágil de proyectos como Scrum, no son el resultado de aplicarla. La transparencia que proporciona Scrum los hace más visibles, lo cual ayuda a priorizar y tomar decisiones (de manera conjunta con las personas implicadas para consensuar la mejor solución). Para ello es necesario disponer del máximo apoyo de la Dirección para alinear comportamientos, recursos y resultados con la estratégia de la organización.
 
Más información

16 comentarios sobre “Métricas ágiles y cuadro de mandos integral para Scrum”

  1. Hola, tengo poco tiempo en Scrum y me he percatado que su filosofía evita incluir cambios en los sprint y allí me asombra que dentro de las métricas que expones se encuentran: Cambios incorporados y requisitos añadidos sobre el alcance inicial del proyecto. A mi entender a un Sprint ya iniciado no se le puede incluir cambios y los cambios de alcance deben ser incluidos al final del Sprint, a menos que el cambio sea tan relevante como para detener el Sprint. En el caso de un cambio urgente, el Sprint se cancela y el equipo se reúne para planificar uno nuevo, esto normalmente mueve las fechas. Entonces agradeceré me ayuden a entender las métricas de cambios que mencionan.

    Muchas gracias
    Saludos desde Santiago de Chile

    Me gusta

    Responder

    1. Hola,

      Respecto a cambios durante el Sprint, estos normalmente se suelen producir porque nos movemos en sistemas complejos y hay aprendizajes que se generan durante el Sprint (tanto por el Product Owner como por el equipo de desarrollo) y que no se pudieron prever. Esto llevar a situaciones como, por ejemplo, las siguientes:

      (a) Se pueden hacer cambios en el Sprint siempre que ayuden a conseguir el objetivo del Sprint, de mutuo acuerdo entre todas las partes (Product Owner y equipo de desarrollo).

      (b) El objetivo del Sprint deja de tener sentido (por algo extremadamente importante que ha sucedido fuera del contexto del equipo, o que ha descubierto el propio equipo) y para aplicar estos cambios no se puede esperar el espacio de unas pocas semanas para finalizar el trabajo en curso y el previsto para el Sprint.

      El caso (b) usualmente es debido a algo que no estuvo suficientemente bien investigado «aguas arriba», falta de investigación o trabajo previo (a nivel de Product Management o Tecnológico). Estas incertidumbres se trabajan, respectivamente, mediante workshops con Stakeholders, usuarios y Lean Startup (i.e. en el «upstream»), o bien con spikes técnicos.

      Cuando estas situaciones comienzan a ser demasiado usuales, es conveniente darles visibilidad para provocar una reflexión al respecto. De ahí que pueda hacer falta una métrica de cambios durante el Sprint, para reducirla al máximo.

      Por otro lado, están los cambios incorporados y requisitos añadidos sobre el alcance inicial del proyecto. En un proyecto en el cual se ha intentado fijar el alcance, los tiempos y los costes (algo prácticamente imposible), a menudo no se da suficiente énfasis a la gestión de cambios (ver Contratos ágiles). En todo momento se tiene que mantener el acuerdo ganar-ganar entre el cliente y el equipo de desarrollo (e.g. si aparecen objetivos nuevos, reducir alcance total si se mantiene la fecha; o bien retardar la fecha si se incorpora todo ese nuevo alcance – aumentando los costes, etc.). Para ello, pueden ser muy útiles herramientas visuales como un «mapa de proyecto», que muestre cómo el alcance del proyecto va cambiando durante el camino y como afectan al resto de parámetros (tiempos, costes, etc.). Ver: https://www2.slideshare.net/xalbaladejo/cas2012-crea-tu-mapa-de-proyecto-para-llegar-a-buen-puerto-v10

      Notar que en un entorno de «desarrollo continuo de producto» normalmente no es necesario hacer seguimiento de cambios, dado que en todo momento se está escogiendo y desarrollando lo mejor posible para ese producto, durante años. Lo más importante es precisamente eso, utilizar técnicas de validación de hipótesis antes de empezar con el desarrollo de la solución.

      Me gusta

      Responder

    1. Hola María,

      El objetivo de tener métricas (y sobre todo sus tendencias) es para que el equipo pueda tener información más objetiva sobre lo que está sucediendo, analizar las causas y actuar en consecuencia. Ese equipo es multidisciplinar y por ello incluye al cliente (Product Owner). Y por el hecho de ser un equipo y perseguir todos los mismos objetivos, es sano que haya transparencia y todos dispongan de datos sobre el outcome (resultados para el usuario final) y el output (producto entregado, features, calidad, etc.).

      Estas métricas, si están automatizadas, deberían estar disponibles en cualquier momento. En cualquier caso, Scrum dispone que haya un tiempo de calidad para que el equipo multidisciplinar piense al respecto de modo que puedan encontrar juntos oportunidades de mejora. Para esto existen dos momentos diferenciados:

      – El Sprint Review, que está más asociado a todo lo relacionado con el valor entregado al usuario final y el producto (métricas de uso del producto, features entregadas, velocidad, etc.). Notar que el análisis del perímetro del proyecto (ROI, alcance, tiempos, costes, prioridades, cambios, riesgos) se puede/suele realizar en el Product Backlog Refinement.

      – La Retrospectiva, donde se evalúa cómo están funcionando las interacciones dentro del equipo, con el resto de la organización, la cadena de valor (o flujo de trabajo del desarrollo), los procesos a mejorar, la calidad interna del producto, etc.

      Me gusta

      Responder

Replica a maria Cancelar la respuesta