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 negritaLas 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:
  • 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
 

 

 

 

Comments

Bajo mi punto de vista, la última apreciación de Tom DeMarco ("hay que trabajar en proyectos que aporten mucho valor y donde el control no sea tan importante") sólo funciona cuando tu negocio es el servicio que proporciona el producto SW que desarrollas.

En este mundo el SW se subcontrata mucho, por lo que no es el mismo valor el que proporciona al propietario del producto (la empresa que paga por el SW) que el valor que proporciona a la empresa contratada para desarrollarlo. En el primer caso y con un proyecto ideal "DeMarquiano", el ROI puede ser muy grande (¿multiplicar por 10 o 100 sería suficiente?). En el segundo caso, el margen es simplemente por hora de trabajo de desarrollador (multiplicar por 1,5 o 2 veces). Es decir, la empresa contratada para desarrollar el SW puede llegar a necesitar más métricas que las que le solicitará la empresa cliente.

Esto me hace pensar que será difícil utilizar el argumento de valor aportado vs control en empresas que desarrollan producto para otros y por el contrario habrá que seguir utilizando otros argumentos para fomentar las metodologías ágiles.
 

Xavi, finalmente expones una mezcla de mediciones las cuales muchas no son necesariamente métricas, sino indicadores que tienen sentido únicamente en un contexto sin posibilidad de repetición, ni son estables y sostenibles al cambiar el proyecto. Eso sucede específicamente con la lista de requisitos priorizada, la lista de tareas de la iteración y los gráficos de trabajo pendiente. Me gustaría acotar que la métrica de completitud también es utilizable en proyectos Agile, de modo que lo que puede variar, son los indicadores o el modo en que se presentan los mismos indicadores existentes en metodologías RUP.

Es importante dejar bien en claro también, que si utilizamos alguna métrica, la misma debe ser seleccionada y aplicarse de un modo cuidadoso, ya que un criterio de calidad de la métrica indica que no debe interferir en el proceso observado, por lo que si modifica las acciones de las personas o los procesos para corregir la métrica, entonces la misma carece de objetividad y es factible de ser falseada.

Mientras que encuentro algo de acuerdo con las métricas de productividad que propones, me gustaría entender algunas que expresas en Métricas de resultados del proyecto. ¿Existen modos empíricos de calcular el valor aportado al negocio? quizás te refieras a la importancia relativa de las funcionalidades liberadas en cada iteración ¿o simplemente es un "punto de vista del cliente"?. Por otro lado, ¿como se toma un valor de velocidad de ese aporte de valor al negocio?.
Yo veo que la métrica de valor acumulado, podría equipararse con aquella de funcionalidades desarrolladas por iteración, priorizadas por su importancia relativa.

Requisitos completados en la iteración y Próximos requisitos a desarrollar, no son métricas, aún cuando lo tengas en un cuadro de mando. Recordemos el carácter de repetición y estabilidad que requiere una métrica.

Cambios y requisitos añadidos sobre el alcance del proyecto, Número de requisitos completados respecto al total de requisitos, Desviación de resultados de proyecto respecto a planificación inicial, también Métricas de calidad y mantenibilidad, como metricas de riesgos, todas ellas son métricas ampliamente utilizadas en otras metodologías de desarrollo no Agile.

Finalmente, me gustaría acotar que las métricas no tienen o no deberían tener una finalidad de control, sino proveernos una descripción objetiva, exacta, reproducible, segura y significativa de nuestros productos, procesos o sistemas, de modo tal que si no podemos confiarnos de ella, algo de aquello que hacemos no es confiable.

Saludos, Javo.

Ciertamente, ni todos los indicadores que aparecen aquí son metricas en el sentido que explicas ni mucho menos son exclusivos de Agile. La intención principal del artículo es mostrar qué tipo de indicadores puede haber en un cuadro de mandos de proyecto de manera que ayude a tomar decisiones según la visión ágil de ir proporcionando el máximo valor a un cliente sin degradar otros parámetros importantes.

Respecto al cálculo del valor, te remito al siguiene artículo: Métricas ágiles y valor - VI encuentro ágil en Barcelona

Respecto a que las métricas no deban tener una finalidad de control, mi opinión es que sí que la tienen, especialmente en metodologías agiles como Scrum, donde el lazo de realimentación para la mejora continua de producto y proceso es el núcleo del propio framework. Y si no, ¿qué sentido tendría medir sin hacer algo al respecto?

Xavier, no creo que tenga mucho sentido medir el ROI en la administración pública. Mi experiencia me dice que, excepto para controlar a proveedores externos y que no se vayan de presupuesto, la administración asume pérdidas y le da igual cuando se le retorna el beneficio de un proyecto.

¿tienes experiencia en este sentido?

Saludos.

Para el cálculo del beneficio de un proyecto se pueden indicar tanto criterios financieros de Retorno de Inversión por ventas como de ahorro de costes (mejora de eficiencia interna de la compañía, ahorro de gastos mensuales, etc.) así como criterios de servicio al cliente.

En el caso de la administración pública se utilizan criterios como el ahorro de tiempo de un ciudadano por poder realizar sus trámites desde Internet, la disponibilidad de infraestructuras que permitan reduzcan los gastos de las empresas que las utilizan, etc. Un ejemplo en que se utilizan criterios de beneficio de proyecto en la administración pública son los Planes Directores. Permiten tener una visión conjunta de diferentes iniciativas a llevar a cabo, priorizando programas de proyectos en función de su beneficio para el ciudadano y su beneficio interno en la propia gestión de la administración.

Que alguna área de la administración pública asuma sistemáticamente pérdidas de unos recursos financieros que son de todos los contribuyentes y que le dé igual cuando se le retorna el beneficio de un proyecto no quiere decir que esto sea correcto y mucho menos que se deba aceptar como normal.

Comentarte que ya empieza a haber experiencias en uso de técnicas de gestión ágil de proyectos en la administración pública, donde se priorizan los objetivos tangibles del proyecto y se hacen entregas regulares para que los impactos en las desviaciones sean mínimos.

Podéis echarle un vistazo al Standard Cost Model, utilizado para medir y reducir la carga administrativa, implantado con éxito en algunos paises del norte de europa (Holanda, UK).

http://www.oecd.org/dataoecd/32/54/34227698.pdf

Muy interesante recopilación!

Al iniciarse en el desarrollo ágil, yo recomendaría utilizar al inicio unicamente la velocidad del equipo. De ahí, conforme se realicen retrospectivas, y se identifiquen los problemas se pueden ir introduciendo métricas que resulten interesantes para observar la mejoría de las soluciones propuestas.

Pero estas no deben ser impuestas al equipo, si no que deben tener una razón de ser.

Xavier:

Muy interesante tu artículo. Voy a hacer referencia al mismo en mi blog.

Entiendo que el agile balanced scorecard es una extensión del típico balanced scorecard, que es una filosofía práctica de gerencia. Aunque escribí esto hace un par de años, lo comparto porque estimo puede ser útil para apoyar la mención de esta técnica.

Por otro lado, si bien la traducción textual de balanced scorecard es, tal como indicás en tu artículo, "cuadro de mando balanceado", recomiendo el empleo de "cuadro de mando integral" o "tablero de comando", que son las formas comunes de uso.

Espero que sea útil.

Saludos y hasta pronto.

Pablo F. Sanchez

Hola Pablo, gracias por la puntualización sobre el nombre más apropiado en español. Ya está cambiado.

Hola Xavi,

Muy buena recopilación. Me interesa especialmente saber cómo medir el ROI. ¿Podrías explicar algo de esto o, en su defecto, tienes alguna referencia en particular a la que pueda acudir?

Muchas gracias,
JMB
http://jmbeas.blogspot.com

Hola José Manuel, existen diferentes maneras sobre cómo medir el ROI. Como es un tema muy importante y extenso, creo que lo más apropiado es hacer un artículo específico. De momento, puedes consultar cómo calcular y medir el valor para el cliente. Para cualquier comentario o aportación sobre este tema, no dudes en contactarme en xavier DOT albaladejo AT proyectosagiles DOT org.

Tu comentario nos ayuda a enriquecer el articulo

The content of this field is kept private and will not be shown publicly.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Allowed HTML tags: <a> <p> <span> <div> <h1> <h2> <h3> <h4> <h5> <h6> <img> <map> <area> <hr> <br> <br /> <ul> <ol> <li> <dl> <dt> <dd> <table> <tr> <td> <em> <b> <u> <i> <strong> <font> <del> <ins> <sub> <sup> <quote> <blockquote> <pre> <address> <code> <cite> <embed> <object> <strike> <caption>
  • Lines and paragraphs break automatically.

More information about formatting options

CAPTCHA
Este formulario es para impedir el abuso de spambots.
Image CAPTCHA
Copy the image characters keeping the upper/lower case.