Una de las obsesiones de los equipos de trabajo y de las compañías es medir. Siempre decimos que lo que no se mide no se puede mejorar. Cómo apuntaba con razón Simon Sinek, aquello que medimos es aquello que ocurre. Por tanto, las mediciones son relevantes. En Scrum, tener métricas son necesarias para conseguir entregar mejor valor. Recordemos que Scrum dispone de varios eventos donde realizamos ejercicios de inspección y adaptación, y tener datos que nos ayuden a tomar decisiones es importante.
Hay muchísimas clasificaciones sobre tipos de métricas: métricas vanidosas o de valor, métricas adelantadas o retrasadas, métricas de éxito o métricas secundarias. En mi clasificación, me gusta hablar de métricas de reporting y métricas útiles. Las primeras son relacionadas con equipos poco maduros, y generalmente se utilizan para reportar. Este reporte puede acarrerar consecuencias negativas si los datos no son los deseados. El problema está relacionado con la cultura de la organización, que no fomenta la confianza y se orienta en medir a las personas y no el resultado de su trabajo.
En este artículo, vamos a estudiar diferentes métricas que se utilizan en equipos Scrum, y porqué pueden ser una mala idea. Por eso, os enseñamos trucos para «trucarlas», y entender que medir a un equipo por ellas nos genera un riesgo a la hora de tomar decisiones.
Velocidad del equipo en Puntos de Historia
Quizás esta sea la métrica más utiliza por los equipos Scrum. La velocidad se puede medir de muchas maneras, pero la mayoría utilizan el concepto de Punto de Historia. En su día hablamos de que el punto podía ser una mala métrica , pero ser una buena práctica que generaba conversación y podía ayudar al equipo a debatir en profundidad.
Sin embargo, es una métrica poco científica, de alguna manera se basa en la opinión del equipo, por lo que es subjetiva. Tomar decisiones importantes con una métrica tan subjetiva, es peligroso, podemos condicionar el resultado en nuestro favor. Por ejemplo, si al equipo le incentivamos con un bonus por conseguir 100 puntos, pueden trucar la métrica para que una feature pequeña valga mucho y no perder su bonus.
De hecho, ¿sabéis un truco para conseguir el doble puntos?, ¡multiplica los puntos que tengas por dos! Los puntos de historia son una técnica interesante, pero siguen estancados en el paradigma tradicional de predecir el futuro.
Además, utilizar la media de puntos obtenidos es peligroso ya que rara vez un equipo repite esa media. Generalmente suelen acabar en un rango, cómo vemos en la gráfica de arriba.
% sobre lo planificado
Cuando implantamos una métrica como la velocidad del Sprint en puntos de historia, es muy natural el querer comparar equipos. Nos toca enseñar que no se pueden comparar equipos. El motivo es simple, cada equipo utiliza sus propias referencias, y sus propias conversaciones de equipo que no se pueden replicar.
Sin embargo, hay personas que desean comparar por diferentes motivos: ver equipos más vagos, proveedores menos fiables etc. En algunas organizaciones se pide utilizar un ratio que permita comparar, y es el % sobre lo planificado en la Sprint Planning.
Medimos el número de puntos o de PBIs que el equipo dijo que iba a hacer en la Sprint Planning comparado con el número real que han terminado. Quedaría una gráfica así:
El rojo representa la cantidad planificada y el verde la realizada.
De esta manera, podemos saber si los equipos “estiman bien”. Este tipo de métricas son peligrosas, porque no ayudan a explicar que en un entorno de conocimiento, estimar tiene muy poco sentido. Además, el acertar o no acertar no nos dice nada sobre el estado de nuestro producto, ni del valor que este aporta al mercado. Es una métrica sencilla, que proporciona Jira, pero que realmente no nos deja pensar en términos de empirismo.
Además, es fácilmente trucable, puedes introducir en el Sprint pocos elementos, e ir añadiendo nuevos cuando acabes. Así, siempre aparecerá por encima del 100%.
Nº de Sprint Goals completados
El Sprint Goal no es un elementos imprescindibles en Scrum. Sin embargo, es muy extendido y muy útil. Se utiliza para poder poner foco en el Sprint sobre qué puede ser importante. El Sprint Goal es una herramienta que guía, pero no podemos medir el éxito de un equipo por cumplir o no un Sprint Goal. Tener una gráfica que mida los Sprint Goals que hemos acometido y cuáles no simplemente nos sirve para recordar que en entornos cambiante, es complicado definir un goal.
Un equipo que no cumple su Sprint Goal, puede haber hecho un buen trabajo, puede ser motivo para analizar en una Retrospectiva. Es más grave no aprender de un Sprint Goal fallido que volver a fallar. Por eso, trucar esto es fácil, color un Sprint Goal muy sencillo y dejar el resto de elementos del Backlog fuera, de esta manera garantizamos su cumplimiento. El potencial problema es que, en esos elementos, perdemos el foco que nos proporciona el Sprint Goal.
% de cumplimiento hasta el MVP
Otra de las métricas famosas es estudiar el % de elementos que hemos avanzado respecto a un objetivo que nos hayamos marcado, como un Producto Mínimo Viable (%). Esta métrica puede tener sentido, pero se suele utilizar de un modo muy predictivo, no favoreciendo la agilidad.
El % de elementos del MVP que han cumplimentado evita que introduzcamos cambios, porque un cambio alteraría ese % y le restaría valor. Imaginemos que estamos al 90%, parece que nos queda poco, sin embargo, introducen otros elementos que nos sitúan en un 80%. ¿Podemos tener una imagen real del estado de nuestro producto?
Además, para poder disponer de una gráfica cómo esta, forzamos el estimar todo el producto (o el MVP). Para ello, un equipo podrá solicitar que todo esté bien refinado, lo cual lleva a poner el foco en funcionalidades futuras que seguramente queramos cambiar. Todo este esfuerzo nos puede llevar a una expectativa que genere daño en el equipo.
Asignar dinero a las métricas Scrum
Las métricas no son buenas o malas, son solo métricas. Muchas de estas métricas pueden aportar información y ser útiles. Sé que muchos equipos Scrum utilizan métricas como la velocidad o el % de avance, sin embargo, el gran problema viene cuando le asignamos algún tipo de recompensa o penalización a estas métricas.
“Una vez que un indicador u otra medida sustitutiva de rendimiento se convierte en un objetivo o incentivo para el propósito de dirigir el comportamiento, pierde el contenido de información que lo califica para desempeñar tal papel” Robert D Austin – Measuring and Managing Performance in Organizations
Por tanto, mucho cuidado con este tipo de métricas, debemos buscar medidores que nos indiquen el éxito de nuestro producto e información relevante que nos permita tomar decisiones. Lo estudiaremos en el siguiente artículo. Si queréis saber más sobre métricas os animamos a leer el libro «Actionable Agile Metrics For Predictability» de Daniel Vacanti, dónde se estudian algunas métricas de valor.
Y tú… ¿Qué métricas utilizas?
Javier, me encantó este artículo, son todo un reto las estimaciones en los proyectos ágiles, (en mi caso opino de los de desarrollo de software) sobre todo tratar de dar a entender que el valor del proyecto muchas veces va más de la mano con la calidad del resultado que con la meta esperada, sobre todo cuando se tienen grandes retos o complejidades. Expones muy bien los casos en los que pueden presentarse errores y como negar que suceden más a menudo de lo que uno deseara ver.
Algo que me funcionó en algunos proyectos y fue saber qué necesitaba el cliente y un estimado de cuánto estaría dispuesto a esperar por ello, así a medida que íbamos avanzando el cliente veía resultados pero también identificaba nuevos requerimientos que se iban sumando al siguiente sprint ¿nos medíamos? sí, pero en este caso por satisfacción del cliente, quien era que evaluava al equipo (resulta ser una buena métrica a mi parecer, aunque hay clientes de clientes). Hubo proyectos que se extendieron por solicitud del mismo cliente otros que terminaron antes y otros que tenían que ser ajustados a tiempos, sobretodo por presupuesto, pero todos con el resultado de tener un producto de calidad y un cliente satisfecho.
Es cierto que se deben tener estimados para poder ver la viabilidad del proyecto pero a mi parecer son indicadores que permiten llevar al equipo en una dirección, avanzar y según el progreso determinar si esos indicadores pueden cumplirse o se requiere de extensiones o recortes por la naturaleza del proyecto.