Existen muchos libros sobre métricas ágiles que deberían utilizar un equipo Agile. En Agile, existe una regla clara: medir software funcionando es la principal medida de progreso. Además de software funcionando, existe otra serie de métricas básicas para poder gestionar un equipo que trabaja con desarrollo ágil de software.
Retorno de Inversión, una de las métricas ágiles más necesaria
Una de las métricas ágiles más importantes es el retorno de inversión, de hecho es la única que realmente puedes comparar entre equipos.Existen muchas métricas ágiles que tratan de averiguar si un equipo trabaja bien, a pesar de que el resultado de su trabajo sea poco productivo para su organización. El retorno de inversión pone encima de la mesa que no estamos aquí para hacer software, sino para que ese software aporte a la empresa. Además, el retorno de inversión se puede comparar entre equipos; con otras métricas ágiles, como los puntos de historia, no es posible.
El retorno de inversión se simplifica calculando ingresos menos gastos. Para calcular los gastos, debemos acuñar todo gasto del equipo, incluido el mantenimiento, operaciones, alquiler del sitio… De esta manera, seremos conscientes de que nuestro equipo está siendo rentable a la compañía o debemos parar y pivotar hacia otro producto o negocio (Business Agility). Como consejo, es magnífica idea transparentar estos datos al equipo para que sean conscientes del resultado de su trabajo. Lo malo de esto es que podemos transparentar sus salarios o sus tarifas, y esto puede ser un problema.

En cuanto a los ingresos, suele ser más complicado de calcular. Si trabajamos con un marketplace de venta directa u otro producto que vendemos directamente, es relativamente sencillo averiguar lo que ingresamos. Si, por el contrario, construimos un software orientado a un servicio interno, deberemos calcular cuánto es el beneficio o el valor que todo eso nos aporta.
Por ejemplo, si estamos haciendo una migración de datos, ¿cuánto dinero perdemos por cada día en el que esto se retrasa? Debemos hacer responsable al Product Owner, o a la figura que vele por el equipo, de que esa métrica mejore. Además, esta métrica debe estar consensuada con los diferentes stakeholders para que podamos inspeccionarla y adaptarla cada vez que revisemos el producto o el servicio que prestemos.
Cycle Time o tiempo transcurrido
La segunda de las métricas ágiles que debemos tener es el cycle time: tiempo que tardamos en resolver un item de trabajo. Una pregunta típica que se hace a cualquier equipo software es cuándo estará la funcionalidad X. Para poder saber esta información, debemos medir nuestros items de trabajo. El cycle time se mide en días, desde que el equipo empieza la tarea hasta el día que la termina. Existe también el lead time, que representa el tiempo desde que nos hacen una petición hasta que la resolvemos.

Muchos estaréis pensando “el tiempo que tardo en hacer algo dependerá de lo que me pidan”. Llevamos toda la vida diciendo que no podemos mezclar peras con manzanas. Imagina que tardamos en “hacer” una pera un día de trabajo (el 90% de las veces).
Si ahora empezáramos a recibir tareas manzana, en ellas, sabemos que solemos tardar unos cuatro días (el 90% de las veces). Ahora, podemos hacer dos cosas, por un lado mezclarlas y dar una estimación de “fruta”, y decir, tardo en hacer fruta 3 días (el 90%). Ahora bien, si somos capaces de categorizar el trabajo antes de abordarlo, podremos dar una respuesta. Y siempre está respuesta irá acompañada de una porcentaje de probabilidad.
Esto es exactamente igual a cuando queremos saber si un caso concreto de cáncer tiene o no tiene cura y nos dan una probabilidad. O cuando queremos saber el tiempo que hará mañana que viene en probabilidad. Pues, exactamente igual se trata de categorizar el trabajo para poder dar una probabilidad y, de esta manera, gestionar las expectativas de los clientes.
Evidentemente, esto se complica por más factores, ¿cuánto tardo en hacer una “manzana” si es urgente? ¿qué demanda de peras y manzanas tengo? (en el ejemplo hemos supuesto 50% de cada). De esta manera, el resto de la organización podrá organizarse sabiendo los tiempos del equipo. Igual que cuando contratas un banquete de bodas, y el dueño te dice “tres días antes me tienes que decir los invitados finales”, ¡tienes que ajustarte a sus tiempos!
Por último, añadiremos que medir el lead time nos permite analizar la capacidad que tenemos para tomar decisiones en la organización. Imagina que en un banquete de bodas se tarda 3 meses en gestionar los papeles, aunque solo tardáramos tres en tener la comida, tendríamos que pedirle mucho tiempo a nuestros clientes.
Delivery Rate o capacidad de entrega
La tercera de las métricas ágiles que todo equipo debería de medir es el Delivery Rate o Capacidad de Entregar. En Scrum, el Deliver Rate se mide con el número de features por Sprint, mientras que en Kanban se mide por el número de items de trabajo por unidad de tiempo. Además, en ambos se suele utilizar gráficos de tendencias para saber si mejoramos.
El Delivery Rate y el Cycle Time están están muy relacionadas, ya que ambas dependen del número de items de trabajo que el equipo hace a la vez (Work-in-progress). La capacidad de entrega de un equipo es una métrica vital para saber si un equipo trabaja correctamente.
Satisfacción de los usuarios es una de las métricas ágiles por excelencia
Recordemos que otro de los principios del agilismo es la satisfacción del customer, ya que debemos centrarnos en él entregando software con valor. Por tanto, la satisfacción de los usuarios es una de las métricas ágiles más relevantes. Sobre todo, cuando hacemos productos o servicio que van destinados a muchas personas, debemos de hacer encuestas, contacto con ellos u otras técnicas que nos puedan dar su feedback o su opinión. Es recomendable crear funcionalidades en nuestro software que permitan la interacción con los usuarios.
Adicional a esto, Scrum y Kanban disponen de eventos orientados a comprender el resultado de su trabajo en términos de satisfacción (Sprint Review o Service Delivery Review respectivamente). Podemos ser poco rentables, con un ROI bajo, pero con un cliente muy contento, para después aumentar los precios o monetizar y así recuperar la inversión.

La velocidad no es una de las métricas ágiles
La velocidad no la considero una de las métricas ágiles a pesar de lo extendida que está entre el agilismo. Entendemos la velocidad como medir el número de puntos u horas ideales que un equipo realiza por Sprint. El motivo para no incluirlo es que tanto los puntos como las horas ideales están orientados a la estimación, y la estimación no deja de ser una opinión subjetiva del equipo. Aunque pueda darnos algo de información, nunca será tan científica como el resto de técnicas ya que están orientadas a medir a posteriori, basadas en datos reales.
En un equipo que tiene una capacidad de cinco features cada dos semanas, podemos defender, ante una petición de negocio de 8 features, que no llegaremos (o que es poco probable). Usando puntos, es más probable que caigamos en la trampa de infraestimar para cometer el trabajo que nos piden.
Por tanto, el concepto de velocidad no lo recomiendo, además de que es tremendamente complicado explicarlo en un área de negocio, lo que supone un punto de historia. Sin embargo, es fácil explicarle lo que es el retorno de inversión, el cycle time, la capacidad de entrega o la satisfacción de usuario.
Y tú, ¿dispones estas cuatro métricas en tus equipos?
Hola Javi, gracias por el articulo. Solo queria comentar algo. La velocidad tambien tiene en cuenta la cantidad de trabajo que has entregado por unidad de tiempo, en este caso puede ser X SP por X dias de capacidad del equipo. Si usas esa velocidad atualizada en el siguien Sprint Planning sabrás que, historicamente podras hacer un delivery de X SP teniendo en cuenta la capacidad de tu equipo en el proximo Sprint. Yo he trabajado tanto en Scrum como en Kanban y me llevo de este articulo buenos consejos, sobretodo la parte de categorizar los items en kanban. Gracias
Buenas Rubén! El problrma de los SPs es que son inventados. Imagina que quieres predecir el tiempo. Puedes basarte en datos históricos de temperatura, humedad, ciclones… Y dar un margen. Otra opción es hacer una encuesta en la calle. Con la encuesta obtienes una predicción, pero es inventada, no es científica.
Los SPs están bien, pero siguen siendo una estimación subjetiva del equipo. De ahí el problema de tomar decisiones con ellos…
Hola Javi, gracias por tu respuesta. Entiendo lo que dices, y en mi opinion, con mi experiencia, por ejemplo con Kanban, una manera de contornar la “incertidumbre” es usar las probabilidades. Lo que veo mas complicado, entrando en un caso especifico de Kanban, es que muchas veces la naturaleza de los items es diferente y aunque los englobamos en la misma categoria, pueden suponer trabajo diferente. Para mi, personalmente, este es uno de los retos mas grandes de Kanban a los que me he enfrentado!
Hola Javier,
igual que Ruben me llevo nuevos conceptos y buenos consejos para implantar en el futuro 🙂 .
Me gustan los conceptos explicados en el articulo y a la vez me cuesta mucho encontrar cómo llevar a la practica algunos conceptos. Por ejemplo, no veo cómo incorporas el ROI a un equipo de desarrollo para un producto interno de una empresa. Que se lo pondría, un valor en € al tiempo invertido en acabar X funcionalidad?
Gracias de antemano!
Mirate este artículo que pongo ejemplos de ese tipo: https://mamaqueesscrum.com/2020/03/09/1417/
A ver si te sirve 😊