Las cuatro métricas ágiles de un Scrum Team, y la velocidad no es una de ellas

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?