Las historias que, se supone, se implementarán dentro de mucho… son desperdicio

En parte inspirado y derivado del post de ayer, me ha parecido interesante dedicarle un post a la necesidad de controlar el tamaño de los Product Backlogs, que, dicho de otra manera, viene a ser tener en el Product Backlog sólo las Historias de Usuario (podría generalizarse a Items, pero bueno) del próximo Sprint o de los próximos (pocos) Sprints, siempre teniendo en mente la idea de tener pocas Historias.

Este es un tema con el que me toca «luchar» con bastante frecuencia. Mucha gente se agarra al «es que tengo compromisos con mi cliente» para justificar proyectos cerrados (que ya no son Ágiles, por mucho Sprint que se tenga), de los de toda la vida: comprometer un conjunto de Historias en una fecha (más allá del Sprint).

Y, aunque algunas veces lo anterior sea cierto, en mi experiencia el 90% de las veces no es tan así. Los clientes suelen pedir compromisos en fechas pero sólo fijan el alcance a niveles de abstracción bastante altos, Epics o superiores, y somos nosotros los que nos ponemos a sacar, desde el inicio, centenares de Historias para cumplir con esas Epics, cuando esas historias podrían irse creando poco a poco, en «Dual Track» y flexibilizando ese alcance «cerrado».

Tener pocas Historias… huele a Dual-Track

Tener pocas Historias huele a «Dual Track» (hay varios post sobre esto, como Agilidad, ¿En qué momento hay que descubrir nuevos requisitos? Constantemente #ContinuousDiscovery o Interiorizando el significado del Dual-Track), es decir, a que lo que se va a ir incorporando al producto se va ideando casi a la vez que se van sacando incrementos, versiones del producto en pre-producción o producción, siendo esas versiones, y el choque con el mundo real, una entrada importante para crear Historias de usuario, frente a la desconexión que supone sacar centenares de Historias, las de muchos Sprints, y olvidarse de la «inspección – adaptación» continua.

Tener muchas Historias lleva por el camino del desperdicio

De entre muchas razones para tener Backlogs ligeros esta me parece tremendamente importante (e interesante).
Quizá recuerdes que hace unos meses una serie de post sobre «Lean de Guerrilla» y como en uno de ellos hablamos sobre el «trabajo superfluo» (Lecciones Lean de guerrilla: cuidado con el trabajo superfluo). El trabajo superfluo son necesidades, tareas, trabajos, etc., que generan los tiempos innecesarios entre que llega una necesidad (una Historia) y se resuelve. Y que podrían haberse evitado.

Esto es un principio Lean (que suena muy Ágil), si abres algo tienes que cerrarlo cuanto antes, sino, el tenerlo abierto mucho tiempo, genera trabajo superfluo: llamadas de clientes, correos, recordar de que iba aquello que hay que hacer (y que lleva abierto mucho tiempo), quejas, el desgaste de priorizar mucha información, etc.

Tener muchas Historias implica tener abiertas Historias que se harán dentro de mucho y eso genera trabajo superfluo, es decir, desperdicio: tener que ordenar todas esas Historias, volver a recordar de que iba aquello cuando toque implementarlas, etc.

Terminando…

Podríamos enumerar más razones que justifican tener los Product Backlogs a dieta. Hay quien, incluso, ha realizado estudios sobre como tener mucha información implica sobrestimaciones (La información irrelevante en una especificación o Product Backlog suele conllevar a mayores estimaciones).
 
¿Complicado tener pocas Historias e ir creando Historias poco a poco? No sé, pero para esto, y otras, estaba el rol del Product Owner ¿no?

Deja un comentario

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

Share This
Ir arriba