Pages Menu
Categories Menu

Posted by on Mar 13, 2019 in General | 1 comment

Buscando desperdicios Ágiles: los Puntos Historia

Buscando desperdicios Ágiles: los Puntos Historia

Hace unas semanas hablábamos de si estimar, como tal, era un desperdicio. Yo te expuse que sí, que lo es, aunque muchas veces es un desperdicio que no se puede evitar, pero que, como tal, como desperdicio, se debía controlar y se debía reducir e incluso… ¿eliminar?

Te contaba en aquel post que estimar era ese tipo de cosas que, muchas veces, no se pueden evitar (lo que no quiere decir que no sea evitable en ciertos casos), porque ayuda otros a hacer previsiones (de cuánto se añade al producto por Sprint, que no hay que confundir con saber qué tendremos en cierta fecha, recuerda, que no te confundan, en agilidad hay fechas pero el alcance es variable).

O es útil porque a nosotros, cómo equipo, nos ayuda a mejorar, a medir la velocidad y a intentar incrementarla (ya sabes, velocidad como ritmo sostenible y no hacer las cosas demasiado rápido metiendo deuda técnica… que luego vuelve).

En esta línea, como te dije antes, deberíamos buscar estimar de la manera que tenga menos desperdicio (o #noestimates, lo dejo para un poco más adelante).

Hay cosas obvias, como el Time-Box y reducir el tiempo de los planning (si usas Scrum), tener un método de decisión en equipos auto-organizados que sea rápido, etc., pero entre todos los anteriores hay uno que algunos equipos ni se cuestionan, que es dogma (aunque, como te reconoceré más adelante, puede que sea inevitable), que es… la estimación con Punto Historia.

Los Puntos Historia, de los que yo he hecho mucho uso en equipos, y de los que he escrito mucho, nacen de la necesidad de ponderar historias de diferente tamaño. Y ahí, en la necesidad que llevó a su creación está la disfunción… tener historias de muy diferentes tamaños es un desperdicio que lleva, entre otros, a tener que usar el Punto Historia.

Sé que en algunos sitos copados de deuda técnica, legacy y walking deads plantear que, a corto plazo, las Historias sean del mismo, o similar, tamaño es utópico (lo que no quita que sea un objetivo de mejora a perseguir). Y por eso existe el Punto Historia.

Pero piensa que si todas las Historias fuesen más o menos del mismo tamaño, y pequeñas (ojo), la velocidad se mediría en número de historias de usuario en “done” al final de Sprint y no necesitaríamos tanto del Punto Historia.

De hecho, eso reduciría drásticamente el tiempo en estimar, sólo habría que basarse en los datos de Historias terminadas en anteriores Sprint, rápido, y no en tener que hacer consensos y planning pokers para ir ponderando cada una de las Historias según un rango de Puntos Historia. Y esto huele mucho a #noestimates.

Pero no sólo eso, el tener Puntos Historia lleva a otras cosas (más desperdicio). Como tener que contar el número de Historias al final del Sprint (no es lo mismo terminar con 40 Puntos Historia y 2 Historias, que con 40 Puntos Historia y 40 historias). Saber si estamos acertando en las Estimaciones (cuándo ponemos un 8… ¿es realmente un 8?). Tener que recordarnos que en las famosas barajas de plannning póker habría que tirar a la basura, por lo menos, de la carta con el 5 para arriba.

Aunque, realmente, recuerda, el problema no es del pobre Punto Historia es de… tener Historias de muchos, y grandes, tamaños. Que no sólo llevan al Punto Historia, y sus derivados, sino también acercan al cascada (esto para otro post, si no lo he escrito ya).

Controlando el Time-Box de los planning, con consensos rápidos, experiencia e historias que no son muy grandes, aun usando el Punto Historia tampoco estamos ante grandes desperdicios, comparado con otras cosas que hay por ahí. Pero si que conviene hacer esta reflexión para no dejar libre al Lado Oscuro, controlarlo, reducirlo o, en definitiva, saltar de nivel y mejorar.

Javier Garzás

Javier Garzás

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.
Javier Garzás

1 Comment

  1. Buenos días:

    Tengo dudas de cómo calcular el Time to Market para un equipo que trabaja en agile. Podeís indicarme si tenéis una publicación que me ayude?

    Muchas gracias

Post a Reply

Tu dirección de correo electrónico no será publicada.

Share This