Un backlog en Jira con más de 20 cosas es… desperdicio. Y a más cosas en un Backlog más desperdicio

Me cuenta nuestra Ms NoBody protagonista de hoy que tienen en su empresa un Product Backlog con unas 700 «cosas» (supuestamente Historias de Usuario).

Y que a la vez tienen un gran problema con los usuarios, porque cuando ven las funcionalidades implementadas en el producto (y las ven cada muchos meses)… rechazan la mayoría. 

Y, por el problema anterior, nuestra Ms NoBody entiende que hay que trabajar aún más y más en detallar, revisar, priorizar, pulir, etc. (venga a echarles horas y horas), ese Product Backlog.

¿Qué os dice la anterior situación querid@s Rebeldes Ágiles? Pues sí, efectivamente, que estamos frente a un caso de Cascadermitis o síndrome del ciclo de vida en cascada autoimpuesto (también llamado Lado Oscuro). 

Volvamos al principio

A ver, una de las grandes debilidades del cascada (dejo vídeo abajo) estaba en las grandes especificaciones de requisitos que se hacían de manera predictiva pensando que, dentro de mucho, una vez implementadas, eso sería lo que querría el cliente… y luego era que no. Que no quería eso (incluso aunque lo hubiera pedido).

Cuando tienes un Backlog gigante, por mucho Jira que tengas, y por mucho que le llames Historias a lo que hay dentro… estás exactamente en el caso anterior. 

Es obvio decir que a Backlog más grande más «historias» habrá ahí abajo del Backlog que de implementarse se implementarán dentro de mucho (dicho desde otro punto de vista, un caso claro de desperdicio por tiempos de espera, como te contaba en el vídeo de abajo hace tiempo).

¿Y cuál fue la solución Ágil a todo esto? Pues tirar del viejo principio que nos enseñó la programación… el usuario sabe lo que quiere cuando lo ve. Entonces que lo vea, y que lo vea antes y de manera muy frecuente y que lo vea en producto real (no papel).

Y de ahí lo de escribe poco y habla más con el usuario y enséñale cosas operativas.

Y de ahí lo del ciclo de vida iterativo e incremental, y el working software (va post), y todo eso.

Hay que crear conversaciones frecuentes con el usuario, no Backlogs gigantes en Jira que nos fuercen a lo contrario

Los Backlog gigantes os llevan por el Lado Oscuro. Os desenfocan del verdadero problema, os hace centraros en perfeccionar un Backlog repleto de cosas que probablemente el cliente no quiera en vez de centraros en detectar lo que realmente el cliente quiere, hablando con él a la vez que se le enseñan versiones (muchas versiones). 

De hecho… ¿no se creó en concepto de historia de usuario para conversar con los usuarios? Pues claro que sí. Entonces… ¿para qué creáis Backlog gigantes que provocan hablar menos con el usuario?

No olvidemos que cada Historia es «una promesa de conversación«. 

Terminando

Todo lo que no aporta es desperdicio, y un Backlog grande es mucho desperdicio, con el problema derivado de la ingente cantidad de desperdicio en ordenarlo, gestionarlo, contarlo, hacerlo que implica.

En el título puse que con más de 20 cosas en el Backlog estamos frente a desperdicio. No sé si son 20, 15 o 25, lo que quiero que pienses es que debe haber pocas cosas. Las del Sprint presente, las del siguiente y poco más.

No dudéis en esto Product Owners o quien sea… borrar ahora sin que os tiemble la mano de la Historia número «20» en adelante de cualquier Backlog (hazle un Marie Kondo a los Jira). Si lo que había era importante ya saldrá de nuevo en el futuro, cuando le llegue su verdadera hora (y sino usa Epics en vez de Historias, que para eso están). Borrar todo eso, además, os va a llevar a trabajar en Dual Track.

Venga, que la Agilidad te acompañe, que mañana es viernes y termina Wandavisión. 

The post Un backlog en Jira con más de 20 cosas es… desperdicio. Y a más cosas en un Backlog más desperdicio appeared first on Javier Garzas.



Fuente: Javier Garzás (Un backlog en Jira con más de 20 cosas es… desperdicio. Y a más cosas en un Backlog más desperdicio).