En varios post lo hemos hablado (aquí hace poco y aquí el año pasado): tenéis, es muy recomendable, que medir la eficiencia del proceso (que no es medir la de las personas, ojo).
La eficiencia es diferente a la eficacia, la primera está relacionada con cómo de bien lo hacemos, con detectar desperdicios, la segunda con el valor que de verdad entregamos.
Hay diferentes maneras de medir la eficiencia, algunas más ligeras y otras menos, pero la elección de una manera u otra depende del punto en el que esté cada equipo.
Número de Historias (items) por Sprint (iteración)
Esto es lo más simple, de hecho aunque uses otra manera de hacerlo, siempre deberías complementarla viendo cuántas Historias (Historias de verdad, ya lo hemos hablado, la importancia de llamar a las cosas por su nombre) se terminan por Sprint.
Gran parte de las iniciativas #noestimates van por aquí. No me extiendo más en este punto, hay varios post sobre ello (como el que te dejé antes) y hasta te grabé un video (el de abajo).
El problema que encuentran muchos equipos es que medir en número de Historias funciona si son todas más o menos del mismo tamaño. De ahí que apareciera otra manera…
Medir en Puntos Historia
Es la tradicional. De hecho, aunque la terminología es confusa, hay quien asocia velocidad con puntos historia (para mí es una de las muchas maneras de medir la velocidad, de medir la eficiencia).
Medir en Puntos Historia puede, en muchas ocasiones, ser la única manera que tienes, pero debería ser una situación temporal, ya que tiene muchos desperdicios o añadidos (como saber también si estamos estimando correctamente los Puntos) y conlleva complementarlo con el punto anterior, medir el número de Historias (esto te lo conté en el anterior vídeo).
Cycle Time
Una tercera vía (sin descartar que hay más y variantes) es el Cycle Time. El Cycle Time es súper antiguo (al menos, en 2011, hace 8 años, en un post muy viejuno, ya te había hablado de él), y es un clásico en el mundo Kanban.
Simplificadamente, el Cycle Time es el tiempo que le lleva a un equipo (recuerda, equipo, no persona) terminar un item (luego puedes sacar medias, etc.), típicamente una Historia.
En un tablero normal (no entro en esto, que ya tienes un post, tableros ágiles sospechosos), con su «TODO», «DOING» y «DONE», es el tiempo que la Historia pasa en el DOING.
Obviamente, tendríamos que provocar que el Cycle fuera lo menor posible, lo que implicará:
- Tener Historias lo más pequeñas (recuerda que las Historias deberían ser pequeñas)
- Tener el mínimo de cosas en el DOING, así el equipo se concentra en cerrar en vez de abrir y en el Swarming (mayor colaboración).
- Evitar desperdicios, como interrupciones, cambios de contexto, reuniones, etc., en pro de reducir el Cycle.
Terminando
No sé cuantas veces he dicho y escrito que medir velocidad o eficiencia (y no sólo lo digo yo, si quieres referencias de «famosos», aquí tienes, y aquí, o aquí) es muy recomendable, pero que no puedes hacerlo descuidando el desperdicio y la deuda técnica, ya que podríais propiciar en hacer las cosas rápido pasando por encima de hacerlas bien, en su justa medida, lo que hará que, a medio plazo, vayáis más lentos (pues aquí lo vuelvo a repetir).
postdoctorado en la Universidad Carnegie Mellon,
EE.UU. Es pionero en management, planificación,
estimación, product management, Agilidad y en la
aplicación de la inteligencia artificial generativa a la
gestión de la creación de productos y servicios
tecnológicos. Fue el único español en la primera
conferencia Ágil de la historia.
- OKRs sin Lado Oscuro, IA para OKRs y alternativas para evaluarlos - 25 julio, 2024
- Por qué seguimos usando técnicas ágiles anticuadas: Efecto Einstellung - 18 julio, 2024
- Cómo crear una IA personalizada (me llevó meses, pero te lo enseño en 2 min) - 11 julio, 2024