Cada Sprint marca el ritmo de un Scrum Team. Todo equipo Scrum demuestra su expertise en función de las métricas que intenta potenciar. Un equipo que está más centrado en las horas imputadas aportará menos valor que otro equipo que se centra en aumentar los usuarios de nuestro producto y mejorar el retorno de inversión. Hemos construído una clasificación en función de las métricas que solemos encontrar en los Scrum Team. ¡comenzamos!
Horas Imputadas
El ejemplo más negativo de un Scrum Team es aquel que está centrado en las “horas imputadas”. Las horas incurridas son una métrica muy habitual en Scrum Team que realizan su trabajo en una consultora para un cliente final. Tratamos de controlar al equipo midiendo sus horas y garantizando su dedicación al proyecto o producto.
Este tipo de métricas aportan muy poca información para que un Scrum Team pueda tomar decisiones que mejoren el valor de su producto. Además, suelen transmitir la sensación de que se le da mayor importancia a la imputación que al trabajo realizado. En muchos casos, se asocia esta métrica con bonus que, de manera diabólica, afectan al ambiente muy negativamente.
De hecho, los equipos que usan estas métricas acaban enfangados en multitud de conversaciones y reuniones, para hablar de la imputación y los tiempos en vez de hablar de los usuarios y su relación con nuestro trabajo. Scrum se convierte en estos equipos en un “zombie” donde seguimos los pasos pero apenas nos aportan un valor.
Tareas Finalizadas
El siguiente nivel también lo podemos calificar de bastante negativo. Consiste en medir las tareas finalizadas. Las tareas, “per se”, tampoco aportan mucho valor. Uno de los motivos es que las tareas, por sí solas, no suelen aportar nuevo producto para los clientes. Generalmente, las tareas unidas, como puede ser: front, back, base de datos, implementación o pruebas, son las que realmente aportan valor. Por tanto, disponer de muchas tareas realizadas no nos mostrará la realidad de nuestro producto.
Además, este tipo de métricas suelen ser muy individualistas y medimos “tareas por persona” o “errores corregidos por persona”. Este tipo de actitudes individualistas y competitivas suelen enturbiar a los equipos y dificultan la sensación de unión necesaria en un entorno completo. ¿Es más importante competir con mis compañeros o centrarnos en el cliente final?
Puntos de Historia Completados
Los Puntos de Historia nacieron del mundo Agile en sus inicios gracias a eXtremme Programming. Los puntos de historia se centran en que valoremos los items de Product Backlog con valores relativos, que representan la cantidad de trabajo que consideramos que nos llevará cada uno de ellos.
Medir puntos de historia tiene varias contraindicaciones. Por un lado, es una métrica muy de equipo y de rendimiento, pero que no nos aporta información sobre el usuario, la calidad o el valor aportado. Además, muchos equipos cometen el error de contabilizar puntos incluso con items sin finalizar. Otros equipos acaban equiparando puntos de tiempo por lo que todavía nos presenta menos información relevante.
Aún así, si un equipo es capaz de medir los Puntos de Historia Completados por Sprint, lo que se conoce como Velocity, podría aportar información sobre la capacidad de entrega del equipo. Ahora bien, al estar basado en unos números inventados por el equipo, siempre corremos el riesgo de estas sesgados en nuestra realidad.
Fechas Cumplidas
Es bastante habitual disponer de hitos con fecha en los equipos. Generalmente, estamos en contra de que existan estos hitos si no llevan asociado un motivo de mercado que sea relevante. Por ejemplo, es bastante absurdo que se le pida a un equipo una fecha de finalización de una determinada feature, cuando apenas tienen información sobre ella, para después exigir dicha fecha.
Cumplir hitos suele ser relevante en los equipos y nos elimina fricciones con clientes o con nuestra propia organización. Ahora bien, tampoco sería positivo correr por cumplir fechas continuamente, entregando un producto de baja calidad al que luego nunca seríamos capaces de mejorar.
Por tanto, aunque estas métricas empiezan cercanas al negocio y al mercado, pueden ser peligrosas si nos derivan en una corriente donde el hito está por encima de todo como si de una hipoteca se tratase.
Historias Terminadas
Las Historias de Usuario o, como se hace en Scrum, los items de trabajo (que es un concepto más general) deben estar orientados a aportar valor. Medir la cantidad de Historias que finalizamos tiene varias ventajas para un equipo Scrum. Por un lado, si es nuestra métrica principal, lanzamos un mensaje muy claro al equipo: queremos mediros por vuestra capacidad de finalizar trabajo. Por otro lado, nos permite saber nuestra capacidad de entrega en el tiempo sin necesidad de estimaciones (como sí necesitan los puntos de historia).
Las Historias de Usuario suelen tener un enfoque funcional y, si están escritas por clientes o usuarios, aportarán valor con una gran probabilidad. Por tanto, medir el número de historias empieza a ser una métrica relevante y más orientada a resultados que las anteriores.
Cuidado, si nos centramos en Historias de Usuario finalizadas tendremos que trabajar el concepto “terminado” claramente. Además, de que cumplan la propia historia, deberemos trabajar toda clase de pruebas que deberían respetarse para considerar que hay una entrega de valor.
Valor Aportado
¡Empieza lo bueno! Siempre decimos que Scrum se centra en la maximización de valor a través del producto que construímos. Un Scrum Team que mide el valor aportado Sprint a Sprint es de los más maduros que podemos encontrar hoy en día.
Valor suele ser dinero, medido de manera directa o indirecta, cuando trabajamos con organizaciones con ánimo de lucro. Cuando trabajamos con “dinero”, puede haber alguna métrica indirecta que debamos potenciar. Por ejemplo, puede ser aumentar los usuarios de nuestra app o reducir el tiempo que tardamos en servir un producto o mejorar nuestros niveles de seguridad. Todo ello se debería poder traducir en dinero en nuestra organización.
Si aplicamos Scrum en organizaciones donde no hay ánimo de lucro, como una ONG o un gobierno, el valor estará relacionado con un beneficio a la sociedad o a un determinado colectivo.
El valor debe ser el efecto que provoca el resultado de nuestro trabajo. Se trata de ir más allá de entregar un determinado producto con features implementadas, sino de estudiar el resultado que estas provocan en nuestro mercado o customers.
Impacto Generado
El impacto es el valor a largo plazo que está generando nuestro producto. Por ejemplo, el beneficio obtenido, el retorno de inversión o el posicionamiento de la empresa en el mercado o respecto a la bolsa. Al tratarse de una métrica a largo plazo, suele ser complejo medirlo en los primeros Sprints.
El impacto a largo plazo debe ser lo que aporte sentido a un Scrum Team. Medirlo en cada Sprint nos ayuda a entender la situación de nuestro producto, pero sin volvernos locos. Un impacto suele ser el resultado de un buen trabajo en muchos Sprints, por lo que debemos combinarlo con el resto de métricas de valor que hayamos determinado.
Y tú, ¿qué mides en los Sprints?
