Valor no es lo mismo que Velocidad, dos parámetros básicos en Agilidad

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

• Acerca de
• Últimas entradas

Javier Garzás

Javier Garzás es Doctor (Ph.D) en Informática, con un
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.

Últimas entradas de Javier Garzás (ver todo)

• Debes crear apps sin saber programar (no hay que saber nada) + Crea Test con IA + Scrum es el nuevo Excel - 12 septiembre, 2024
• Las 6 técnicas prompting + 1ª Ley del Manager Oscuro + Mantenlo sencillo, estúpido - 5 septiembre, 2024
• Guía de Métricas Ágiles (versión agosto 2024) - 22 agosto, 2024