Valor no es lo mismo que Velocidad, dos parámetros básicos en un proyecto ágil

Normalmente, hay dos parámetros (llámalo métricas, si quieres, o puedes) básicos que en una «metodología» ágil (lo de metodología viene entre comillas, ya sabes que realmente son buenas prácticas, más que metodologías) suelen o debieran revisarse, al menos, al final de cada Sprint, cuya su revisión y seguimiento, normalmente, es responsabilidad del Product Owner (si bien uno de ellos, la velocidad, la suele actualizar el equipo técnico), que, igualmente, son normalmente usados como base para la estimación y el seguimiento y que, frecuentemente, son olvidados y confundidos: el valor y la velocidad.

Velocidad

Por velocidad, el conocimiento popular entiende, como puedes ver con más detalle en ¿Qué es la velocidad en un proyecto software (normalmente ágil o Scrum)? Aclaración de dudas frecuentes, la suma del número de puntos historia que se estimaron para cada historia de usuario (o ítem en general) que fue terminada durante una iteración o sprint.
En general, es la cantidad de trabajo estimado que se ha completado, ojo estimado, o las horas estimadas, según la unidad que uses, pero esto es más raro y lo normal y recomendable es usar puntos historia. En el anterior post hay más información de por qué la velocidad es trabajo es estimado y no real.

Valor

Normalmente, la priorización de historias de usuario, el propio product backlog, viene dada por el valor que estas aportan al cliente o al negocio. A mayor valor, mayor prioridad.
Como ya contamos en detalle en el libro “Cómo sobrevivir a la planificación de un proyecto ágil”, el concepto “valor” de una historia de usuario, como era de esperar, no tiene una única definición, sino que depende del producto, del momento, etc.
Como es lógico, no existe un criterio universal para dar valor, priorizar historias de usuario o requisitos, depende de cada negocio. Si bien es importante que cada equipo fije los criterios por los cuales hará la priorización. En cualquier caso, es bastante frecuente observar tres parámetros principales a la hora de determinar el valor de cada requisito (Cohn, 2005):
– Rentabilidad de incorporar el requisito.
– Coste de incorporar el requisito.
– Cantidad de riesgos que minimizará la incorporación del requisito.

Un equipo y su product owner deben gestionar ambos, valor y velocidad

La velocidad me dice el ritmo que tiene el equipo, el valor… lo que acertamos a la hora de añadir “código” al producto.
Yo puedo ser muy rápido pero muy malo en valor. Puedo tener mucha velocidad y un cero en valor añadido al producto, si, por ejemplo, las historias de usuario que me proporciona el Product Owner realmente no las quiere para nada el usuario final.
El valor es más responsabilidad del Product Owner, la velocidad del equipo. Y medir velocidad sin medir valor real entregado, no el que yo pensaba… es un error.
Ya sabes… “la potencia sin control no sirve de nada”.

Valor y Velocidad no son los únicos

Que destaque en este post la importancia del valor y la velocidad, no debe hacer olvidar otras métricas, como, por ejemplo, las métricas de felicidad, ya sabes eso de Un equipo “feliz” es más productivo y por ello está de moda medir la felicidad

jgarzas

Ph.D. en informática, Postdoctorado en la Carnegie Mellon (EE.UU) e Ingeniero en Informática.

Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.

También soy profe de la Universidad Rey Juan Carlos.

Dejar un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *